It's just a plan... if no one cares enough about particular parts of
it do actually do them, that's another issue altogether.
There are pre-built packages with the nightly builds.
However, it is true that no "stable" tag has been created, ie no one
or group has defined "stable" or done testing according to the
definition to declare that a certain revision of the branch is "stable".
On the other hand, I think those using it consider it at this point to
be pretty "stable", though there are known issues, such as with Double
versus BigDecimal, and with Minerva as the transaction manager.
-David
On Nov 15, 2008, at 4:21 AM, Bruno Busco wrote:
David,
I have read the "Release Plan" but it is hard for me to find a match
to what
I see on the SVN.
In particular I do not see those key policies actuated:
- An initial pre-built package will be created and made available
to help
get people started with the branch
- Once a release branch stabilizes an initial "stable" release tag
and
pre-built package will be issued
Where are "pre-built packages" ?
I am sorry but I must say that the "Release Plan" seems to me 1) not
actuated and 2) not as standard as a "release candidate" would be.
My two cents,
- Bruno
2008/11/15 David E Jones <[EMAIL PROTECTED]>
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
