On Jan 16, 2009, at 12:37 AM, Bruno Busco wrote:
How we want to do this is a good question. I suppose defining a
release
target is the way to go, and we can use that for bug reporting
after the
branch is created as well.
Yes, this is the way JIRA is supposed to be used.
True, but is it useful to us to use it that way?
If we do that this next release could simply be "release2009", or
if we
want to be more specific and perhaps use the Ubuntu model (and
assuming
we're planning for a release in March) we could use something like
"release9.3". I think I like the simple release2009 better...
Any other opinions?
I would prefer the "release9.3" scheme, since it will allow us to
have more
that one release in a year (just in case). It will give very soon a
more
precise indication of the time in which the release was done.
The version string can be created in JIRA as release9.3, than, if
for any
reason we miss the month (or if we finish earlier) we will rename it.
If there are no objections I will create a "release 9.3" version
scheduled
for march 2009.
I'll acknowledge that more than one release per year could happen, but
I'd be really surprised to see it happen. When a release branch is
done it seems to take many months to back-port enough bug fixes from
the trunk and get fixes in from other sources to actually make it
fairly solid and functional.
We also have the issue of update paths and scripts or whatever. If we
have too many releases it causes a lot more confusion for prospective
users about which release to use, and also causes more effort to
maintain more update paths between releases. If we only release every
1-2 years then it is generally pretty clear which one to use.
Actually, I've spelled a lot of this out a long time ago here and as
far as general concepts and issues go I don't think much has changed:
http://docs.ofbiz.org/display/OFBADMIN/Release+Plan
-David
