Sounds workable to me. David Ashley
On 01/11/2011 09:13 AM, Rick McGuire 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
