Hi David (and others),
> 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)?
To have a reproduceable and tested state of code. I would like to take
the perspective of a business end-user here once again. If I was running
my company on OFBiz (we plan to do so, by the way) I would want to make
sure that a release contains code that has been properly tested. So if I
run 1.0 now and I get the chance to upgrade to 1.1, I would expect that
there is no broken functionality because I have real people doing their
daily work using that software and also our customers would not be too
happy if they receive wrong invoices because some developer felt like
checking in some untested changes to invoice generation and I just had
the bad luck to update to the SVN version which had that in.
Also a release is about support. Put yourself in the shoes of someone
making a living of implementing and supporting several customers that
run their individual OFBiz installations. How are you ever going to
compare behaviour, against what would you ever file a bug, how would the
customer ever be able to tell what version he's running if there are no
releases?
What I could imaging and would like to suggest though:
Have you thought about not having releases of the whole package at a
time, but releasing components. You could version the framework, the
"execution environment" so to say and then version the indidual modules
(Marketing, Partners, ...). That would allow for a user to upgrade what
he needs to upgrade. You should still use some Linux package
maintainance system as a guide how to manage compatibility, basically
how to do SCM in the original sense of the word.
So I could find out, that in my installation I am running:
OFBiz Base: 1.0.12
OFBiz CRM: 1.1.3
OFBiz Accounting: 1.0.0
Now the team which is maintaining the accounting module feels like
releasing version 1.1.0 which still requires OFBiz Base 1.0.5 or higher.
I have 1.0.12, so I should be ok.
Next month, you might have a release of CRM which is 2.0.1 because is
has made a major leap forward in functionality. For that to happen, you
had to update the Base framework as well. So CRM 2.0.1 requires at least
OFBiz Base 1.1.0. Get the idea?
IMO the key to success of OFBiz will be to make sure you have enough
sub-communities which are going to focus on vertical functionality as
well as on locales. But keep them on apache.org and by all means avoid a
situation where a "basic OFBiz" is real OSS but to really use it in a
business, you need the X, Y and Z components which are 300 USD, 2500 USD
and 400 USD per seat and only work with an outdated version of the
package itself. Or even worse: You are not going to find any compatible
versions of X, Y and Z at all to even get them installed.
This kind of threading and pseudo-commercialization was and is a massive
road-block to the success of something like Compiere and IMO OFBiz
biggest opportunity is to just do better here.
Regards,
Torsten
David E Jones schrieb:
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
