whichever of these commits corresponds to releases should be tagged and have the tags pushed.

if you're not sure how to do that, review your commits with git log, it should list the commits and their hashtags, then
git tag [version#] [commit-hashtag]
where you replace the bracekts with actual values
then git push --tags
that way we can easily switch to the release version and not have any current compile errors and such when developing against carpentersblocks

2nd recommendation, use another . for hotfix #'s, forge complained about versioning when you when from 1.87 to 1.9, because forge assumes 87 > 9, 1.8.7 and 1.9.0 would be more appropriate

Good suggestions.

Regarding the tagging, is this possible when I commit & push within Eclipse?

i'm not really sure how the eclipse git interface works. The way I work with it involves housing the repo in a separate location and using Buld Path -> Link Source.

I think in team->advanced->Tag... you can set tags, though i'm not entirely sure how to make sure they get pushed.

If you choose to try out the Build Path -> Link source method, you can use tortoise git or some other such windows git client if you're on windows. Otherwise getting binary versions of git to work with on unix command line is usually simple for both mac and linux.

http://git-scm.com/book/en/Git-Basics-Tagging

Found it, if you go to the Git Repository Exploring perspective and Expand your repo, under Tags you can right click and push the tag, just make sure the target its refs/tags/tagname
source:
http://www.youtube.com/watch?v=q6E9alq-5ls

its definitely easier to work with the command-line commands, git tag and git push --tags

Finally found the tag option, will try and (remember to) tag stable versions here on forward.

its actually possible to retroactively tag old release versions too (provided you have a commit on the repo that corresponds to that release), the tags are kept seperate from the commits, so you can tie them to any commit you like when you create them.