Hi Jacopo:
Its nice to see this kind of thought going into a release
strategy. Thanks for the effort. Please see my comments inline.
Note, this is just my opinion based on years of working with big
complex IT organizations. These are the kind of "users" who
ultimately would be implementing OFBiz (I hope...):
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
