stable svn branch?

Eric Stadtherr estadtherr at gmail.com
Mon Jan 15 05:53:11 CET 2007


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 at gmail.com <mailto:estadtherr at gmail.com>




More information about the Dev mailing list