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).
Jacopo
