Matt, I agree. Normally you have a release target, like Release 0.5 and a set of tickets assigned to that release. As enough tickets are closed for that release it will enter an Alpha stage. Once it has a relatively decent amount of stability it will enter a Beta 1 phase. If the software needs a few more refinements before the release it may get a Beta 2 or Beta 3 phase. Finally there is a short lived Release Candidate which some early adopters may try and report back any big problems which will need to be resolved before the final release.
In SVN it may look like this... tags\release-0.5.0-alpha tags\release-0.5.0-beta1 tags\release-0.5.0-beta2 tags\release-0.5.0-rc branches\release-0.5.0 It would be good to keep the branches directory uncluttered of every little change and just track the significant releases. For anyone experienced with SVN, I have some questions. I am still not comfortable with how SVN handles tagging differently than was done in CVS. I do not fully have an understanding of how branches are different than tags in SVN. Are branches still sticky in SVN? Do tags stay put like they do in CVS? Brennan On Sun, 14 Jan 2007 23:34:16 -0600, Matt Kaatman <[EMAIL PROTECTED]> wrote: > Hey Eric, > > You don't have to release a stable version often, although it is a nice > thing to do. > > Normally to get to stable you'll freeze new features and have a > specified amount of time to squash bugs. > > Once the bugs in the tracker are worked out you create a stable release. > > If a critical bug is found, you fix it in the stable branch and move the > tag. > > Matt > > Eric Stadtherr 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 >>>>> >>>>> >>>>> >>>> >>>> >>> >>> >>> >> -- Brennan Stehling Offwhite.net LLC [EMAIL PROTECTED]
