On Dec 28, 2006, at 12:57 AM, Jacopo Cappellato wrote:
David E Jones wrote:
...
Still, the first priority after graduation is to do a community
supported branch "release". Again given the size of OFBiz relative
to the size of the community, we don't have resources to do a full
QA pass before issuing a release, so the release process for OFBiz
will be centered around a community effort to maintain a branch
that will have bug fixes, but not new features, as anything would
be maintained with a priority of stability over progress (new
features, etc).
Are we sure this is the best way to go? My fear is that no one will
ever maintain these releases (submitting patches for them etc.).
A slightly different approach could be this:
1) we issue releases regularly and very often, let's say once every
two months
2) each release will not undergo a full QA pass, however we will
try to issue it when the code is pretty stable (e.g. not
immediately after a big refactoring)
3) every time we do changes in the trunk that could cause backward
compatibility issues (changes to the existing data model, seed
data, jars etc...), we document them somewhere and if possible we
provide upgrade scripts or instructions (in order to upgrade from
the latest release only); when a release is done, these
instructions are delivered with it ("Upgrade notes from release X
to new release X+1").
I think this approach (with its pros and cons) is easier to
maintain by the OFBiz community (because it's not so different from
what we are doing now) and could be acceptable by the OFBiz's users
(because it's similar to what most users are doing now, i.e.
staying up-to-date with the trunk to minimize upgrade costs).
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?
On that last bit, whatever we do with the releases having an official
wiki page with all non-backward-compatible changes listed on it with
the revision number for each would be a good thing to do...
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)?
-David
