I have to chime in about tagging and branching. From what I am reading on this thread a few of us have different ideas of how this should work.
The way I ran tagging and branching with CVS was to tag the trunk and branches at different times just so I could have named snapshot. The branches were always for releases. They may have just been internal releases, but they represented an isolated branch of development off of the trunk. Experimental work would stay on the trunk while the release branches were carefully monitored with few changes. With SVN tagging and branching are pretty much the same thing. Either way it is a snapshot of the code base.
For the release branches it is best to maintain a list of known issues. This could be placed on the wiki with a list of the releases. As issues arise for a release on a branch they would be added to the list of known issues to warn off anyone who may be considering moving to a newer release.
See this wiki near the bottom as an example.
http://www.jetbrains.net/confluence/display/ReSharper/Nightly+Builds
They are using Jira and we can achieve much the same with Trac. Resolved issues on branches just need the commit comments to include the ticket number in the form of #123 and Trac will link it to the ticket. That will help show users which issues were resolved on a branch.
Perhaps branches will just go to a single decimal point while tags will have two.
branches\release-1.0.0 branches\release-1.1.0 branches\release-1.2.0 branches\release-1.3.0 branches\release-1.5.0
tags\release-1.0.1 tags\release-1.0.12 tags\release-1.0.19 tags\release-1.0.23 tags\release-1.0.59
The as bug fixes are made to the trunk they would be merged the the current release branch and given a tag. Once we have this in place we can have recommended release. And like the Jetbrains example, we can rate the releases on the number of known issues and the severity of the known issues.
From what I am reading it sounds like experimental changes are broken off into branches and perhaps later merged into the trunk. That is contrary to what I typically see on open source and proprietary projects. A branch is generally a way of freezing development so you can stabilize the release by identifying and eliminating the known issues.
I have been frustrated today by past bugs creeping back into my RC installation even though they were apparently fixed a long while back. I have no idea what version to grab from SVN. It seems like as I install a more current version I am just running in circles. For my personal projects I create clearly marked branches.
http://svn.offwhite.net/trac/SmallSharpTools.UrlMapper/browser/branches http://svn.offwhite.net/trac/SmallSharpTools.EmbeddedScripts/browser/branche...
Brennan
On Sun, 14 Jan 2007 21:53:11 -0700, Eric Stadtherr estadtherr@gmail.com wrote:
Matt,
That's an excellent idea in principle; however, the challenge is coming up with the process to decide what's stable. How bad does a bug have to be to prevent a revision from getting tagged? Who does the evaluation? Who "moves" the tag?
Automated unit tests with some scripts that manipulate the repository are usually the answer to this, but the maintenance of unit tests is usually a non-trivial effort.
The easiest thing to do is just keep a working copy of your own, and make your own decisions as to whether something is stable enough for your environment.
Matt Kaatman wrote:
Couldn't you have a tag called stable and move that tag with each stable release so that someone who checks it out will always be able to get the latest release tagged as stable without picking a specific version?
(So you'd probably double tag with each stable release. One tag with the version number that is constant and one that is called stable which moves with each stable release.)
Eric Stadtherr wrote:
Jason,
In general, branches aren't intended for "stable" snapshots - they
exist
as ongoing work areas to manage some parallel development that needs configuration control but cannot impact the baseline. Branches are usually merged back into the baseline when the parallel development is complete. In Subversion, the convention is to create "tags" for snapshots of revisions that have some meaning. If you look in the RoundCube /tags directory, you'll see the latest revision that was considered "stable," i.e. the v0.1-beta2 version.
Jason wrote:
I was checking out svn.roundcube.net and it looks like there isn't a branch that I can checkout/update that'll always give me the latest stable release. Am I missing something, or could a /branches/stable be created that was always the latest stable released version?
Thanks, Jason
-- *Eric Stadtherr* estadtherr@gmail.com mailto:estadtherr@gmail.com