This document has been around for a while, but pretty clearly
describes options available and which to take when:
http://docs.ofbiz.org/display/OFBADMIN/Apache+OFBiz+Getting+Started
This is a problem that goes back to the beginning of OFBiz, and is
fairly unique to community-driven enterprise software. You won't see
the same issue with "commercial open source" like SugarCRM or Compiere
or OpenBravo or the like, because they develop using a commercial
model, and not an open source model.
-David
On Nov 17, 2008, at 9:25 AM, Markus Studer wrote:
David E Jones wrote:
- Framework release
- gather ideas from people in a confluence page (TODO: add my own)
- complex UIs, GWT, DOJO, etc renderers for widgets
I've been thinking about the framework release and our current
Release 4. Release 4 will be two years old in a few months. A lot
has been done to the project since the R4 branch. How about making
a Release 5 branch (whole project) sometime around Spring?
I think that's fine. Hopefully by then we'll have more framework
things done.
What I'd really like to hear for releases is what people plan to do
with the release branch. In general in order to facilitate
collaboration and such it is best to use the trunk. Unless we have
a lot of people using OFBiz OOTB then it may not make sense to do
releases at all, even "lite" releases like these release branches.
Release Handling is tricky and I'd like to give you some infos on the
kind of problems we're facing with dealing with release 4.0, trunk,
patches etc.
We've successfully used OFBiz in multiple projects based on a pre 4.0
release (~6 months before release 4.0). We minor changes to
framework parts, bigger changes to applications and release 4.0 was
helpfull for troubleshooting as it is a more stable reference than
the trunk that moves fast.
There were parts that we wanted to give back to the community and
that's
were problems start.
E.g. we translated some applications to german and wanted to give that
back. Unfortunately, instead of .properties in Release 4.0 there are
.xml files in trunk and no easy way to merge that somehow into the
trunk. Currently, I'm redoing some of the translations that we already
did to get that back into the trunk!
Next problem we face: Which version of OFBiz to use for future
customer projects:
- our internal adapted pre 4.0 version (more than 2 years old with our
own internal bugfixes)
- 4.0 release (2 years old with the bugfixes from the community)
- trunk
Option 1 -> our pre 4.0 code
not really a nice option as were loosing all the optimizations and
work the community did in the last years. Backporting new
functionality will get more and more difficult
Option 2 -> Release 4.0
would give us a stable, proven base for development. Unfortunately,
this
release is 2 years old and newer functionality is missing. No idea,
how
to cope with release 4.0 in a few years. (we also thought about a
migration of our code to release 4.0 but we're not sure if that is
worth the effort)
Option 3 -> trunk
would give us all the new stuff. Difficult to estimate how risky that
is, i.e. how stable the trunk is and what effort is needed to fix
those little bugs in trunk. Once we start with trunk, we won't
integrate newer code from trunk as those changes contain both
bugfixes and new functionality (bugfixes are great, new
functionality not as one needs a stable base to start custom
development -> that way we're back with option 1 in a few years :) ).
One thing you also need to consider is that not having releases has
some subtle consequences. Everyone who checks out from trunk has
his personal "release". Once you find bugs, you fix them locally but
to give back such fixes becomes more and more difficult -> you need
to check out the trunk, recreate the problem, apply the fix, submit
a patch. As every user has his own "release" (snapshot of time x),
working together becomes difficult (e.g. there is no usergroup using
SVN 718108 that has similar problems that can help or other users
that we can help).
Suggestion:
- Framework: Periodical Release (e.g. every 2 years), as the
framework part is stable and mature and it should be possible to get
the functionality defined
- Applications: Is more a strategic decision as it defines more how
OFBiz is used, i.e. more out-of-the Box or as a base for other
products. There is lot of work involved to get releases done, i.e.
release management, define functionality for a release, get
concensus on new features, upgrade paths, documentation. But it
would clearly help to promote OFBiz. Difficult question that remains
is how often to release: release often to get new features in vs.
release sparsely as OFBiz drives your business.
Markus
