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
