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/branches Brennan On Sun, 14 Jan 2007 21:53:11 -0700, Eric Stadtherr <[EMAIL PROTECTED]> 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* > [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> -- Brennan Stehling Offwhite.net LLC [EMAIL PROTECTED]
