One point of clarification: it seems like the word "stable" here should be replaced by "bug free", as in [release branch] tends to be less "bug free" than the trunk. The release branch is inherently more "stable" because it doesn't change as much (ie the definition of stable), and I think Jacopo is really referring to the idea that we've discussed before that stability is not the same as being "bug free".
About the six month release period, I'm not so sure about that. It sounds like the idea is to give up on high quality releases in order to increase marketing. There are two problems I see with this: 1. this may not have a positive effect on marketing, I don't know but it seems like a large number of less meaningful press releases will not be as helpful as a few significant ones (yes, I know large companies tend to do lots of less meaningful press releases, but many of these stories are just another form of paid advertisement and press organizations like to carry them because name-dropping increases ad views for ads from other companies, and ad purchases from the companies mentioned, and therefore revenue; unfortunately Apache OFBiz doesn't benefit from this sort of status, so the story really needs to _mean_ something to get attention 2. I still think quality releases are important, and there are certain people in the community who consider this important and are willing to invest in and contribute to such an effort; if we move to more frequent releases it makes it much more difficult for the people who want to work on high quality releases, and decreases the chances that the project will ever have a vetted binary release -David On Feb 15, 2010, at 3:49 AM, Jacopo Cappellato wrote: > I know this subject has been already discussed several times in the past, but > I still would like to rethink our strategy for releases in OFBiz. > I am under the impression that, considering the release branch 9.04, that is > our latest release branch: > * there are more users than maintainers > * because of this, no real maintenance plan, test strategy etc.. has been > created around it from the community of users and interested parties (in fact > we were not really able to officially release it) > * a lot of new users start eveluating OFBiz from that instead of the trunk > * it is rather old, several new features are missing and also code > improvements (that could fix bugs etc) > * because of this, it tends to be less stable than the trunk > > The main cons of this situations are the following: > 1) not real interest in maintaining a release branch means that we will not > be able to spend time on it and officially release it: the OFBiz community > will miss the advantage of using the marketing channel represented by a new > release > 2) new users will get the wrong impression that the project is slowing > improving if they just get the releases > 3) it is much easier for a user to stay up to date with the trunk rather than > with a release: I mean that there is no guarantee that one day someone will > build an upgrade plan from the old release to the new one... users of the old > release may be left behind forever > > What I suggest is based on the following assumptions: > 1) community is not ready or interested in maintaining releases > 2) new users prefer to start evaluating OFBiz with a release instead of the > trunk > 3) it is good for the project to announce new releases often > 4) because our current policies (slowly increasing number of committers, peer > reviews, etc...) our trunk is (and will be) more stable than older releases > > Here is what I suggest: > A) define an official release plan that says that we officially issue a > release every approx 6 months (just to give you an idea): since there is no > way to define a set of features that will go in the next release, our > releases will be based on dates instead of features; but of course we can > discuss the exact time of a release based on what is going on 1-2 weeks > before the release date > B) there is no guarantee that patches will be backported to releases, that > upgrade scripts will be created from release to release > > It is true that the ASF policies ask that a release, that represents the code > that is distributed by the ASF to the larger audience of users, is a "stable" > deliverable; but if we continue with the current approach, even if it is > intended to get a stable and maintained release, what we are really doing is > distributing the code in the trunk (this is what we suggest our users to use > instead of the release), not the "stable" release. > > What do you think? > > Jacopo > > >
