Unless I'm misunderstanding I think the answers to your questions are
earlier in this thread. As implied by the name, the planned release
branch date would be March 2009 (hence the 9.3, in the Ubuntu style).
As for a "stable" branch with errors worked out, the comments about my
expectations of at least three months and our experience with
release4.0 of 6-9 months are the best answer available (AFAIK anyway).
As for "safe" extensions to OFBiz... changing classes is a no-no and
can usually be avoided by some sort of contribution with either the
literal change you need, or something that makes the class more
flexible so that you can intercept elsewhere with the change you need.
In general, class extension is NOT a very good form of creating
extended functionality that is easy to maintain, no matter what OO
folks say. You can do a lot with the cart by creating custom request
events instead of using the default ones, and if the ShoppingCart and
related classes were a bit cleaner and more flexible (which has been
discussed a number of times, even recently) then even more could be
done.
-David
On Jan 19, 2009, at 5:59 PM, Luke Prentice wrote:
hi guys,
my colleagues (rajib khan and guy gershoni) and have been working
with ofbiz
for over 3 years now. we're currently going through the process of
"upgrading" to the latest trunk of ofbiz. we've done this
periodically for a
few months and tried really hard to keep our own customisations
abstracted
out (so merges are less painful).
i've been following this discussion with interest. because of the
pain of
merging in changes from a not-totally-stable trunk (i know that it's
not
stable -- cos it's a development trunk!) we need to decide when to
"cut our
losses" and move away from the development trunk. some of the recent
changes
have been radical enough to slow down our development significantly.
so... we'd like to stay "connected" to the development community and
contribute back changes where that's useful (eg
https://issues.apache.org/jira/browse/OFBIZ-1906). plus we can of
course
benefit from fixes in the trunk. however, on reflection, the
destabilisation
that results from merging is too great a burden for us to keep
doing. (eg,
commit 712932 to ShoppingCart.java was a deep problem for us because
we're
extending a number of classes in this file).
[aside: a potential discussion is whether or how can ofbiz users
customise
classes? is it bad practice? in our case we have modified the
shopping cart
because we want the OrderItem to be extended too.]
hence my interest in this topic. specifically because our team would
like to
"lock on" to a stable release branch. we're way ahead of release
branch4.0
and have noticed release9.3 appeared recently.
given the list of "must do" and "would like to get done" *before*
release9.3
is bedded down, what is a reasonable time frame for this to happen?
short version: *when will release branch 9.3 be committed as stable?*
the answer to that will determine whether we remain connected to the
trunk
and seek to commit/merge changes and "play our part" in the community.
many thanks,
luke.
On Sun, Jan 18, 2009 at 6:16 PM, David E Jones
<david.jo...@hotwaxmedia.com>wrote:
Sounds like you're leaning towards using the trunk... ;)
-David
On Jan 17, 2009, at 11:58 PM, Brett Palmer wrote:
Maybe every 3 months was too optimistic. I just seems like a year
is a
long
time to wait for another release. Especially if you are working
with one
of
the new ofbiz applications like workeffort and you want new
features as
they
become available..
Brett
On Fri, Jan 16, 2009 at 10:56 AM, David E Jones <
david.jo...@hotwaxmedia.com
wrote:
My reply to another message seems to fit this exactly:
============================================
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
============================================
To sum up: we could certainly try it (I'm up for trying
anything), but I
think with the lack of resources that a single release branch was
able to
rally it would be even more distracting and dispersing of
resources to
have
multiple release branches close together. My guess was 3 months
to get
bugs
worked out of a release branch, and I think it really took more
like 6-9
months for release4.0. If we do releases closer together I don't
think
they
will EVER get cleaned up with the bugs worked out.
-David
On Jan 16, 2009, at 5:21 AM, Hans Bakker wrote:
I think this is good proposal.
it should be automatically scheduled.... and update script is a
good
idea...
so please (re)read this proposal.
Hans
ps. the attachment not really get trough?
On Thu, 2009-01-15 at 23:42 -0700, Brett Palmer wrote:
Here is another proposal for release branches. Rather than
doing a
release branch every 1 - 2 years how about doing it by calendar
and
releasing a new branch more frequently (e.g. every 3 months).
The
objective would be to stay as close to the trunk as possible
while
still providing stability for production releases.
All appropriate fixes for the release branch would go back into
the
trunk. Then after 3 months we would create another release
branch and
start the process all over again. The community could also
provide
update scripts to help production deployments move from one
release
branch to another. This is currently a pain now and is one of
the
reason I think people don't update their production deployments.
I'm attaching a graphic that shows how this proposal would work.
I'll also put in another plug for community driven test cases.
The
test cases would be used to determine when the release branch was
stable enough for a recommended general release.
Brett
On Thu, Jan 15, 2009 at 6:07 PM, David E Jones
<david.jo...@hotwaxmedia.com> wrote:
I just setup your jira permissions Bruno (sorry for forgetting
that earlier) and you should be able to do this now.
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.
As for the version name of the release we should talk about
it. Thinking about it now we have discussed doing a release
branch once per year, and perhaps once every 2 years. Perhaps
we should version the release with the year? I've never liked
that approach a whole lot, because in many cases it is less
meaningful that a major/minor version number, but for OFBiz
the release branches are time based so perhaps a year makes
sense.
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?
-David
On Jan 15, 2009, at 4:24 PM, Bruno Busco wrote:
David,
could you create the new version in JIRA so that we
can schedule these
issues on it and have them displayed in the Road Map?
https://issues.apache.org/jira/browse/OFBIZ?report=com.atlassian.jira.plugin.system.project:roadmap-panel
Thanks,
-Bruno
2009/1/16 David E Jones <david.jo...@hotwaxmedia.com>
On Jan 15, 2009, at 3:33 PM, Adrian Crum
wrote:
David E Jones wrote:
What do we still have that is
up in the air for refactoring,
cleanups,
and enhancements? I know quite
a few have been worked on
recently but I'm
not sure of their exact
status, but here are some that
come to mind:
https://issues.apache.org/jira/browse/OFBIZ-1868
Yes, that would be a good one to get done.
There may also be other framework versus apps
issues that need to be
resolved, actually I know there are (Bruno
brought one up today in fact).
-David
--
Antwebsystems.com: Quality OFBiz services for competitive prices
