I think that we are all close to the same idea. Only a little bit is missing: what we call now "Release branch" should be renamed to "Release Candidate branch". This would mean that what is contained in that branch is somewhat that is going through the release process (testing, bug fixing, documenting, etc.) and so it is candidate to become a Release.
When we are happy with the tests done on the RC branch we will tag the branch and create the real Release. The bug fixing on the RC branch can continue and when we rae happy again we can tag it again. What is the issue on doing this? Isn't it the standard way to handle releases? About releases, branches and tags names: I propose to use a name as "RC_10.4" for the next release candidate branch. After a while when no major issues will reported on this branch the release can be done that is the "OFBIZ_10.4" tag can be done on the RC branch. After some bug fixes on the RC_10.4 branch we will tag it again as "OFBIZ_10.4.1", "OFBIZ_10.4.2", etc. The third number will mean that the release is actually a "mantained", "bug fixed", release of the 10.4. Does this make sense? -Bruno 2010/2/24 Matt Warnock <[email protected]>: > On Wed, 2010-02-24 at 08:22 +0100, Jacopo Cappellato wrote: >> Are you planning to fix them or to donate some resources (developers and/or >> money) in order to fix them? Or are you asking other to do this? >> BTW, do you really think that commercial or open source releases are done >> when companies think there are no bugs? Really? > > Well in my experience it is unusual for most software, and it isn't > often in Debian (once about 4 years between releases), but yes, that is > EXACTLY when a new Debian Stable is released. :) > > -- > Matt Warnock <[email protected]> > RidgeCrest Herbals, Inc. > >
