On Dec 28, 2006, at 2:09 AM, Jacopo Cappellato wrote:
David E Jones wrote:
I guess it depends on what the goal of doing a release is. In my
mind the goal should be to create (over time...) a stable set of
artifacts that people can build and deploy on if they choose not
to go with the latest/greatest.
What you're describing is interesting, but how is that any
different than just using the latest from SVN with a little timing
based on knowing what is going on added in, and keeping a list
somewhere of all non-backwards compatible changes and their
revision numbers?
Yes, you have described pretty well what I'm suggesting; I'd only
add to these that we should also create the upgrade services (and/
or upgrade instructions) every time we commit a non-backwards
compatible change in svn. As you said, this is not so different
from what we are (implicitly) suggesting to do right now (as a best
practice to stay up-to-date with the trunk) but I think that it
would be nice if the community will officially support it for a few
reasons:
1) it's often difficult for users to pick a 'stable' svn snapshot
2) it's often difficult for users to keep track of important
changes between their revision and the trunk
3) since it is not so different from what we are suggesting right
now, it will not add a huge cost maintaining these extra processes/
releases
The problem I see, trying to look at it from the point of a
prospective end-user, is that this sort of frequent release doesn't
help me a lot.
1. If I want a good, stable version where I don't have to worry about
bugs, which one do I choose?
2. If I realize there is no perfect version because of constrained
community resources but at least want to group together with others
to support a certain release, which one do I choose when there are so
many coming out so fast?
3. Once I have chosen and have been running for a while and want to
upgrade OFBiz, which newer version do I choose (related to the above
questions) and how much work is it going to be to not be able to
update from that version to the version I choose, but instead go
through the upgrade processes for every version between that one and
the one I choose?
But, back to the main point: what is the goal of a release in your
mind (and in the mind of anyone else reading in too)?
I'd like to get the opinions from others too.
Personally I think that releases (or release instructions/plans)
should at least help users to keep their system/data in sync with
the main trunk, minimizing the upgrade costs and simplifying the
users' decisions (i.e. "should I upgrade now?").
Of course it would also be great to have a real 'stable' releases
(with patches for them etc...) as you are suggesting (and I really
think we could implement the two approaches simultaneously since
what I've proposed could be the basis of a real release management)
but I'm not sure the community will really maintain them...
I'd say if people want to stay in sync with the trunk, there is
nothing better than the trunk for doing so... In my opinion doing
some sort of regular "release" would only make it more difficult for
people to keep up with the trunk and participate in or contribute to
OFBiz because they would never be quite up to date.
What I'm hoping for is a single, infrequent branch that people can
rally around and maintain together. If we only do one of these each
year or so then there will never be a question about which one needs
fixes back patched to it as we'd only support at MOST 2-3 of these at
any given time. That would mean people would need to update at least
once every 3 years, but of course that's just a random artificial
number and being a community driven thing if there is a group that
wants to continue to maintain an older branch then great, more power
to them!
People looking for a good release to use if they are asking question
#1 above would use the latest release in the latest stable branch
that is at least, say, 3 months old. For people asking question #2
above they could just use the latest stable branch as-is from the SVN
directory for that branch and participate in making the branch better.
-David
