I disagree. every complicated process is made up of simple processes.
the level you approach it, is what makes it complicated.
An I believe the process can be modeled and implemented.
just as the tests are now, as limited as they are.
what it takes is a commitment by each one that changes the code base to
put their smarts in the direction of what does it take to get from here
to there as far as migration.
one way for instance is to use Diffs or even the patch itself as a basis
for driving the migration.
then is it a matter of tools to use the diffs and patches to run a check
on customization.
I do maintain my own SVN, I would not be this far if I did not.
however it does not help to compare code that outside that of the ofbiz
svn(component that are customized but not part of the code base of ofbiz)
The bottom line, for a business, is overhead to maintain it hard cash.
Jonatan Soto sent the following on 9/22/2010 5:00 PM:
What I see here is that it is not as easy to create an upgrade system for
this kind of project. Perhaps the nature of it, it's a good reason. Remember
that Ofbiz is an ERP system and tries to cover as much as it can different
businesses, so IMO it's not like a proprietary product or another kind of
open source project where it is not a common practice to change the trunk
code by everyone and also allows to easily install plugins, mods,
extensions, etc.
IMO, I can say that one good chance to achieve this is to separate the
framework from the apps, already discussed in a lot of posts and I think it
is strongly accepted by the community. This will get the ability to extract
an important piece of code which I think is not regularly altered, at least
in my case, I've modified some apps but never the framework.
From my point of view, the hot-deploy works fine and it's fairly enough for
a lot of customization purposes and maintain the trunk code untouched. But
it seems to me that sometimes is not enough mostly when an adaptation of an
existing app, concretely i18n enters the scene. For example I found to be
very complicated to move the entire Accounting module, IMO the one that
requires more i18n, since it is related with a lot of modules. In this case
I have had to customize in-place. I have some ideas about that, but I prefer
to discuss this in a proper post.
BJ, I believe that your problem is related with the number of installations
do you have/maintain so a little solution may be (if you aren't doing yet)
the vendor drop technique (
http://svnbook.red-bean.com/en/1.5/svn.advanced.vendorbr.html). But I
suppose it's only valid if you decided to use the trunk version from the
beginning and kept up to date so often...
On Thu, Sep 23, 2010 at 12:44 AM, Jacques Le Roux<
jacques.le.r...@les7arts.com> wrote:
From: "Adam Heath"<doo...@brainfood.com>
On 09/22/2010 03:33 PM, BJ Freeman wrote:
Am it to gather by this that you can do a direct SVN update and all your
customization continue to work?
say from 9.04 to 10.04
Ofbiz has never supported upgrades. I agree with BJ here.
Database tables can change. Not all changes are automatic. Such changes
are not listed in a simple place(in the source).
Values in tables can change. No upgrade conversions are provided(again,
in a simple place).
Is this useless?
https://cwiki.apache.org/confluence/display/OFBTECH/Revisions+Requiring+Data+Migration
Jacques
To solve this, requires running older ofbiz on older database, doing a
test upgrade to each and every new version, and then seeing what is
different. This is a *very* hard problem, not easy to automate, and takes
smart people lots of time. This is not something you can just force on the
community. No one has sat down to do this very busy, hard work, so it
hasn't yet been done.
If you run trunk, then it is up to you to solve any per-version upgrade
problems.
However, official releases should really have appropriate, detailed,
upgrade instructions.
