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
