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
