Well, the first step would be to copy the releases\4.1.0 to branches\4.1 and update the minor version number so this builds as 4.1.1. Then apply any fixes that have been made since 4.1.0 to this branch. From there, we just use that branch for all 4.1.x bug fix releases. When we release 4.2.0, we create releases\4.2.0 and branches\4.2 accordingly. We might also want to delete branches/4.1 at that point if we're certain that all subsequent bug fix releases will be based on the 4.2 stream.
I'll see if I can find some time over the next couple of days to get the 4.1 branch created. Rick On Tue, Jan 11, 2011 at 10:27 AM, Mark Miesfeld <[email protected]> wrote: > This definitely sounds good to me. > > I'll need to study the details a little to grasp exactly how it works, > but since it comes from a working model you're familiar with, I'm > assuming it works. It seems it is similar to what I was trying to do > with the test suite. > > It would make it much easier to do one thing I'm really in favor of, > and that is doing bug fix releases at relatively short intervals. I'd > like to do a bug fix release at least every 6 months. > > -- > Mark Miesfeld > > On Tue, Jan 11, 2011 at 7:13 AM, Rick McGuire <[email protected]> wrote: >> In most of the Apache projects I'm involved with in my day job, the >> svn source trees have the following organization: >> >> trunk -- the most recent working version of the code, with all new >> function and fixes applied. The release number is generally a more >> major increment because there is new function involved. >> tags\* -- released versions of the code. Once a tag version is >> created, it is never updated. This corresponds to our "releases" svn >> directory. >> branches\* -- a working copy of a major release to which fixes for a >> released version can be applied. This generally builds to the next >> minor increment. >> >> For example, with the Apache Geronimo server I work on, we have three >> major release branches that are currently considered active (2.1.x, >> 2.2.x, and 3.x). The 3.x line is developed on trunk, there are >> branches labeled 2.1 and 2.2 to which fixes to those versions get >> applied, and there is a tree in tags for each of releases for each >> version. For the 2.1.x line, we're up to release 2.1.7 and the 2.1 >> branch will build a 2.1.8 release (well, 2.1.8-SNAPSHOT actually, but >> that's a complication I don't really want to introduce here). >> >> The rxapi looping bug is a good example of this. For testing >> purposes, it would be really nice to be able to create a version of >> 4.1.x with the fixes applied without having to worry about any >> instabilities that might be in trunk due to in-progress enhancements. >> Additionally, it would be nice to have a branch where bug fixes can be >> applied immediately rather than retrofitting a whole pile of fixes >> should we decide that a bug fix release might be a good idea. >> >> So, here's what I propose: >> >> 1) Create a copy of the 4.1.0 release branch in branches/4.1 >> 2) Change this code tree so it builds with release numbers 4.1.1 >> 3) Bug fixes against 4,1.0 should be applied to both trunk and the >> 4.1.1 branch immediately, if possible. There may be situations, for >> example, where a fix might easier to fix in the trunk rather than in >> branch, so the backport is not necessarily automatic. >> 4) The process will repeat each time a new major release is rolled >> out (e.g., there will be branches/4.2, branches/4.3, etc.) >> >> I think this will make it easier to manage fixes, rollout test fix builds, >> etc. >> >> Thoughts? >> >> Rick >> >> ------------------------------------------------------------------------------ >> Gaining the trust of online customers is vital for the success of any company >> that requires sensitive data to be transmitted over the Web. Learn how to >> best implement a security strategy that keeps consumers' information secure >> and instills the confidence they need to proceed with transactions. >> http://p.sf.net/sfu/oracle-sfdevnl >> _______________________________________________ >> Oorexx-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/oorexx-devel >> > > ------------------------------------------------------------------------------ > Gaining the trust of online customers is vital for the success of any company > that requires sensitive data to be transmitted over the Web. Learn how to > best implement a security strategy that keeps consumers' information secure > and instills the confidence they need to proceed with transactions. > http://p.sf.net/sfu/oracle-sfdevnl > _______________________________________________ > Oorexx-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > ------------------------------------------------------------------------------ Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl _______________________________________________ Oorexx-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/oorexx-devel
