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
This is probably true. But to get a better understanding of who is using what,
maybe we could look into getting download statistics? I have already put in a
request to the infrastructure team for this, but have not heard anything back
from them. Maybe a project committer has more clout and could get this
implemented? Without that, we are just speculating about who is doing what with
the code.
* 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)
I thought all the bug fixes were retrofitted to the release? Is this not true?
* because of this, it tends to be less stable than the trunk
How could the release be less stable than the trunk if bug fixes are applied to
the release and 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
Project committers should consider this behavior pattern: Most people
evaluating code will not want the latest release. They will patiently wait
until someone else has taken on the risk (and reward) of debugging it. Do not
think that just because the project releases a new release of OFBiz, that
everyone will stampede to get it. Far from it. Now if we had download
statistics we could verify my claim, but I'd be willing to bet real money, that
the only people who will jump to download this new release will be project
committers.
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
I think you mistake "user" with "committer". What "user" is actively trying to
stay current with the trunk? Just some food for thought.
What I suggest is based on the following assumptions:
1) community is not ready or interested in maintaining releases
Only the "committers" are not interested. Users out there may have a different story to
tell. Personally, I'd like to see releases "maintained".
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
True. Very true.
4) because our current policies (slowly increasing number of committers, peer
reviews, etc...) our trunk is (and will be) more stable than older releases
Again, why? I thought bug fixes are committed back to a release if appropriate.
Is this not the case?
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
Don't release every 6 months. That's crazy. Once a year is sufficient. Put in place a real release plan including
features, fixes and upgrade instructions in advance and then work towards making OFBiz something more than just a
developer's playground. Make it "stable" by setting out in advance what "stable" means. And then
work towards making each release meet the "stability" requirements. Just releasing something every 6 months
or a year does not a "stable" release make.
B) there is no guarantee that patches will be backported to releases, that
upgrade scripts will be created from release to release
If so, then what is the point of even having releases? Just have nightly trunk
builds and everyone is happy.
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.
IMHO, one of the true benefits of going with the ASF is the structure and stability they enforce on
umbrella projects. Why not use these "restrictions" to the project's advantage instead of
trying to circumvent them. I think I'm agreeing with you in that maybe "we" should start
pointing users to releases instead of trunk code. Just a thought.
Ruth
What do you think?
Jacopo
