Our general strategy up to this point has been to create a GA branch like 1.1 to apply bug fixes on that branch. From there you release bug fix releases like 1.1.1, 1.1.2, ... 1.1.N. The 1.1 name implies the same as 1.1.x. It would be nice to use the same technique across our projects regardless of what is chosen.
This keeps it so history shows your bug fixes on that branch since it was copied over from the trunk. I can do a svn log --stop-on-copy and see all the bug fixes that took place across releases on that branch.
The trunk is always the bleeding edge unless of course you have some experimental branches or big bang like work that may cause breakage.
On Apr 25, 2008, at 6:03 AM, Emmanuel Lecharny wrote:
Pierre-Arnaud Marcelot wrote:
Hi,rename it to 1.1.1, so that we all know which version is being baked.
I'd like to propose a renaming of the "1.1.0" branch (https://svn.apache.org/repos/asf/directory/studio/branches/1.1.0/) to "1.1.x" (https://svn.apache.org/repos/asf/directory/studio/branches/1.1.x/).
This branch is (and will be) used to prepare the minor (service) revisions for the 1.1.0 release and, as the 1.1.0 version is out now, I think it makes no longer sense to name it 1.1.0. <http://1.1.0.>
Another strategy is to name it 1.1, and have the version either stay at 1.1-SNAPSHOT (till the end of time) or 1.1.1-SNAPSHOT and update it after every release. I don't think renaming the branch after every release will improve the ease of svn archeaology should someone want to examine past history.