Git tags


#1

the git repository seems to lack tags for version 2.0.28 and 2.0.29, is this done on purpose? I think that having versions correctly tagged could be useful for reference


#2

Ah, sorry, I regularly forget to add those. Thanks for reminding me - I’ll tweak my build scripts to do it automatically.


#3

more about this: I think you are tagging commits with the simple command

git tag version_name

this has the downside of creating a “lightweight” tag, which is simply ignored by “git describe” command, and the GUIs that rely on that don’t display the latest tagged version correctly

instead, I think you should make annotated tags, with syntax:

git tag -a version_name

this will ask for a description message similarly to commits, that can also be specified on command line with -m

more about this: http://drupal.org/node/1073690


#4

I could get into a rant about the stupidity of having two types of tag, but haven’t the energy. Thanks for the heads-up.


#5

Speaking about this subject… jules, what is your policy about bumping the version number and tagging it?

Do you tag a new version when development is stable and shows no known bugs, or do you do that when you begin adding new features/important changes from the version before?

I’d like to know in order to regularly merge into my production code the latest JUCE code that has the least chances of having open bugs. In the first case, I can safely merge the tagged commits. In the latest, the most stable commits should be the ones preceding the tagged ones.

Waiting your word on this (what about a “stable” git branch?)


#6

I don’t have a formal policy - I just generally bump the number when everything feels like it’s been stable for a while. Certainly the versions that are tagged should be the best ones to use.