Check out the "Release Plan" document on docs.ofbiz.org...
-David
On Nov 15, 2008, at 1:58 AM, Bruno Busco wrote:
What about using a "release candidate branch" in place of a "release
branch"
?
With this I mean:
1) the release candidate branch could be started at any time (even
from the
trunk as it is right now)
2) the actually open JIRAs should be selected and the "fix version"
field
should be changed to the new scheduled release candidate for what the
community agrees to be included in the release (even some new
features).
This gives a clear idea to all the community of what needs to be
done to get
the release done. And I guess all the active community will try to
have them
done with a high priority. (The answer to the question "When will we
have
the new release?" will be "When we will have all the scheduled issues
closed. Please give them a look and attach a (tested) patch."
3) when all the JIRAs scheduled on the release candidate are closed
the
release can be done, a tag is created and the release (maintenance)
branch
is started where only bug fix are committed.
4) in addition to this I would create a tag from the release
maintenance
branch whenever a reasonable amount of fixes are done.
I think this approach is very standard, no extra efforts are
requested that
we cannot do and gives a clear idea to everybody of where we are.
-Bruno
2008/11/14 David E Jones <[EMAIL PROTECTED]>
On Nov 14, 2008, at 9:46 AM, Adrian Crum wrote:
David E Jones wrote:
I don't mean to dilute the framework release effort. But at the
same
time, it seems to me issues are coming up in R4 that have been
addressed in
the trunk.
While to some extent this depends on the type of issue, in
general issues
in the 4.0.0 branch should be fixed in that branch by the "sub-
community"
that has formed around the branch. If things are not getting
fixed, to me
that means the branch has not attracted enough of a user and
contributor
community. I don't know how to fix that problem...
It is true that most of the bugs discovered in R4 are fixed as
they come
up. I was thinking more along the line of the kinds of things that
were
corrected by refactorings and such.
I've run across a number of people using R4 and service providers
who are
using R4 for their customer's deployments. In addition, Opentaps
is based on
R4. So, there is a sizeable R4 community out there, even if they
aren't
vocal on the mailing lists and such.
I guess the goal or purpose of a Release 5 would be the same as
Release 4
- to provide the opportunity to build on a target that isn't moving.
I agree that there needs to be a community of people who want it
and are
willing to support it. I was just tossing the idea out there, but
at this
point in time there doesn't seem to be much interest.
These are good points Adrian. Don't let my "Devil's Advocate"
approach
scare you away or make you think there is no interest in doing
these. I
imagine there are many people who would like to see release
branches happen.
Part of the reason I wrote some doubts about it is that there is an
open
source mantra of "release early, release often" and I was wondering
about
that... What if we took the opposite approach of "never release"?
It's the
total opposite extreme and I'm not completely sure I like the idea,
but it
has some really interesting points. For example it encourages:
1. community interaction, even for those who are just "users" and not
sending things back
2. frequent upgrades by all users to resolve issues
3. community responsibility, rising the priority of things like
automated
testing, and giving people more reasons to get involved with that
testing
and contribute tests
4. base application design decision refinement to help people with
regular
updates and resolving issues while not creating new ones
5. something the press can write about that is very different from
things
done in other places
6. a social experiment in collaborative enterprise software that is
yet
unseen in the world
Of course, there are disadvantages, like:
1. a smaller user community because the prospect is scary
Maybe that's it. I really think that if as a community we work more
on
automated regression tests and such we'll have a higher quality of
software
in the trunk than is in the release branches, partially because of
what
Adrian mentioned (and I alluded to) where certain types of issues
require a
lot of refactoring and aren't simple fixes that can go into a release
branch.
Anyway, something to think about. In a way doing release branches
breaks
important aspects of the "never release" approach because things
like #1, #2
and certain of the others won't happen, or won't happen as much.
Actually,
it applies to more, maybe especially #3. If we never release,
developers
have no excuse of making things unstable, or committing without
thinking
about things, or throwing stuff out for they are designed well.
There is no
excuse of "if people want something stable, use the release branch,
and
leave us alone!"
I'm still for doing another release branch early next year (and
continuing
with 18-24 months between branches), unless a lot of people find
the "never
release" philosophy interesting.
-David
