On 3/31/07, Mark Miesfeld <miesfeld@gmail.com> wrote:
On 3/31/07, Rick McGuire <object.rexx@gmail.com > wrote:

On 3/31/07, Mark Miesfeld < miesfeld@acm.org > wrote:

I have a few questions on process for the 3.1.2 release, but also on the
process in general.

2.)  The process in general:  When we have the final 3.1.2 release, will the
3.1.2 branch be branched into 'releases' and frozen?  I am assuming that at
that point the 2.1.3 branch will be merged back into trunk, is that correct?

Probably more correct to say it will be moved to releases.  Because there are things done to the branch that are part of generating the release (such as updating version numbers and stuff), the branch is not generally merged back.  Any fixes applied to branch should be manually updated in the trunk.
Thanks Rick. 
Shouldn't the version numbers be updated in the trunk also?  Say in May someone checked out from the trunk to pick up a change, like the one you just did with the .stream error messages.  Shouldn't the version then be 3.1.2, or not?

That's something I'm not really sure we've established yet.  In my day job, I work on a several open source projects with the apache foundation (all in Java).  In that world, it is fairly common practice that artifacts in the trunk have version numbers that indicate it is an intertim version.  For example, with java projects, this is typically done by adding -SNAPSHOT to the version number.  So, the release process is generally

1)  Take the branch for the release, remove the -SNAPSHOT from the version identifier.
2)  Bump the release number for trunk (but keep the SNAPSHOT indicator). 

All builds done directly from trunk thus indicate it is a dev release. 



Mark Miesfeld

Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
Oorexx-devel mailing list