If you value clean work practices, I would suggest that instead of commenting out code (which is an OK enough practice in the very short term, i.e. when we're talking a few weeks or less), prefer to use a source control system (Git, Mercurial, Subversion, etc.) instead:
Move the feature's code, and all that's specifically related to it and not used by other code, to a separate feature branch (i.e. a fork off your current development branch). Make sure the code is completely removed in the main development branch. That way, all you will have to do to reactivate the feature is to merge the feature branch back into the main development branch. What you will not have to do is undoing the commenting-out on a line-by-line basis (running the chance that you forget to uncomment something, somewhere).
It might be a little bit more work, but a much cleaner work practice than commenting out code. Commented-out code has the habit of accumulating over time, and it's often never uncommented again (against previous expectations). For that reason, unless a piece of commented-out code has explicit documentation stating why it's commented out, and when it should be uncommented again, I tend to purge commented-out code from a code base whenever I stumble upon it.
For the same reason, I would suggest that you don't only disable/remove the "triggering" code of a feature, but all other code that is also related to only it (even if it would never have any effect if you removed the core feature code). Because, if you eventually don't put the feature in the next release, you might forget about the dependent code. So treat it the same was as the "core" / triggering feature code.