Cameron,
This is a good message in general, though I'd like to clarify a few
objectives we have already discussed related to this:
1. the first branch is coming up soon, mainly because we wanted to
time it soon after the incubator graduation which has just recently
happened
2. we do not plan to EVER freeze new development in the trunk;
instead for "stable" releases we'll create a branch and probably a
release from it _immediately_ in order to get a community boot-
strapped around it, and then hopefully after a few months of back-
patching bug fixes and fixing bugs unique to the branch it will be
nice and stable and ready for anyone to real lean on in production
(barring errors introduced in customization and configuration of
course... ;) )
3. not only the data model and services should be considered in the
backwards compatibility maintenance; people can (and should) create
derivatives of artifacts up and down the layers of the architecture,
even form and screen definitions and such... Of course, I don't think
we'll ever "guarantee" backward compatibility, we instead plan to
"manage" backward compatibility the best we can and try to help
people with custom stuff depending on code in OFBiz to not get hit to
hard when inevitably change (if anyone wants some that doesn't ever
change, they should take a release branch and NEVER update, or
something along those lines, or hire an omniscient being that will
build something to handle everything they will need in the lifetime
of their business)
-David
On Dec 29, 2006, at 2:41 AM, Cameron Smith wrote:
My 2 metical after following all the other arguments.... I would
be happy to help with detailing and preparing the release
procedures and regression tests (see below).
1. Goal of a Release
I agree with David that it should provide a stable set of
artifacts. NOT just at the level of screens, but at the level of
services and entities because almost everyone who deploys OFBiz
customizes it in some way. This is different from some end-user
apps which periodically do a complete rewrite of the internals but
keep the interface sufficiently recognizable so as not to alienate
the customer base (ex. MS Office, Tomcat 3 -> 4 -> 5).
OFBiz has a great advantage here because all core funcionality
exposes an API which is basically the sum of the services and
Entities involved, plus a few other standard config structures
(ofbiz-component.xml and controller.xml). Therefore I believe we
should structure our compatibility objectives around services and
entities. For instance, if we say that release B is "API backwards
compatible" with release A, that means extensions which depended on
services and/or entities from release A will still work with B.
Some of these services or entities may have added optional
parameters or new nullable columns, just as long as they keep
providing the old API.
In contrast, if someone writes their extension to also depend on a
certain Util class or simple-method, the releases make no
compatibility guarantees here.
For instance I am writing a module now, to do end-of-month VAT
reconciliation according to Mozambican regulations. It uses
certain services in the accounting module as building blocks. If a
future release removed or altered the API of those services, I
would be stuck. If a future release added a few extra optional
parameters to those services, I would not be forced to alter anything.
2. Release versioning policy and testing
Based on the above discussion and also the contributions made thus
far, I would suggest the following approach.
a) We aim at ONE release per year, coming out every June or
thereabouts. I think it is better to have ONE deliverable per
year and meet it than two or three which immediately slip. The
Ubuntu project has a larger community, a rich private backer (Mark
Shuttleworth), started with a much more established set of release
tools and procedures (from Debian), and still slipped Dapper from
being 6.04 to 6.06. Note that only 6.06 is LTS (long term
support), and 6.10 is not.
b) The SysPro argument for continuous updates is interesting but
rings completely false with the target market I have in mind -
small bricks and mortar commercial enterprises. From my experience
both in UK and MZ, these places know their businesses and once they
have got ERP support for their core processes, they prefer to get
on with business instead of constantly looking for new features.
They prefer to workaround minor feature incompatibilities than risk
disruption and instability.
c) So an annual release in the middle of each year gives us this
rhythm:
*At the start of the year, start stabilizing any new or reworked
functionality.
*In May or thereabouts, core commiters insitutue a freeze on big
changes and only let in bugfixes
*In June, make the new branch, test it and commit fixes to the
branch.
*End of June, version the branch and announce it as a release.
*At this point, commiters let big changes back into the trunk
*In parallel, the release maintainers do bugfixes ONLY on the
release and merge them back into trunk wherever it makes sense.
*By December, anyone who takes the latest version of the release,
should be guaranteed that it is pretty stable. If they want any
features they go for the SVN trunk.
d) Using the definitions here: http://apr.apache.org/versioning.html
*A release from year N should be minor version compatible with the
release from year N-1
*Once the release from year N is out, it should only suffer patch
versions
e) Testing. David makes a good point about the vastness of OFBiz
and the difficulty of guaranteeing that a certain version is
stable. I believe that in the long term, the only solution is to
build up a suite of regression tests. Its a lot of work but it is
definitely worth it, for the security it gives you when refactoring.
I believe we need to build up two layers of tests:
*Integration tests: black-box tests which test the APIs of all the
services and entities. I am already using the OFBiz TestContainer
framework for this. I suggested some tweaks to it a few months
back but didn't get any feedback at that time.
*Web Tests: white box tests which exercise/simulate a browser and
test core use cases (e.g. create invoice, receive order, etc,
etc). I am already using Watir for this but there are other
frameworks. I would be happy to write up a little tutorial for how
to do this on the OFBiz wiki.
3. SVN policy
I believe we SHOULD use branching, because it allows for a stable
release in that it receives bugfixes ONLY, which can be backported
to the trunk if necessary. So basically at any one time, the
community is supporting 3 streams: the trunk + last release branch
+ upcoming release branch.
4. Modules
I agree with David that we should NOT try to separate modules. At
most releasing framework and applications as two separate chunks,
as David suggests, but I think even that is a secondary priority to
having stable supported releases. There are several reasons for
this....
a) For Commercial ERPs, the "modules" are largely a way of
justifying a larger bill to the client. The boundaries between
modules are often gerrymandered so that when you buy modules A and
B, you have to buy C as well just because it has one little
function that a "normal person" would say logically should be part
of C.
b) OFBiz modules are largely structures to facilitate team
development. They are not fully independent - there is a lot of
interdependence at the entity and service level - and this is
natural given that the whole point is an Integrated system.
Businesses are borne integrated and often departmentalize as a side-
effect of growth. Later on they spend huge efforts trying to
reintegrate once more.
c) I don't believe the community is big enough to support the
additional effort of unpicking, specifying and maintain "clean
interfaces" and data-flow consistency between all the modules. I
believe that effort would be better spend stabilizing the APIs at
service and entity level as discussed above.
d) David is right about the Linux packaging systems. Whether RPM
or DEB, they have a laudable ideal but in practice can make a
nominally simple job inordinately complex. So people have to
write (very) clever helper tools on top of them (ex Synaptic on top
of apt on top of dpkg on top of deb!!)
5. Documentation
I agree with Torsten that we need to lower the cost of entry to
OFBiz, but I also agree that we need to ask "lower the cost of
entry to what?".
In fact, contrary to what Jacopo suggests, I believe that there IS
a set of core functions which I believe there is a huge target
market for in much of the world, among people who could never
afford SAP. These functions are fairly consistent - and they don't
need to come with "bells on". And I would imagine its not a
coincidence that OpenTAPS has chosen several of them as the focus
for its Financials module.
Basic Accounting (Journal Entry with separate Posting, Balance
Sheet, Trial Balance, Data export to Excel)
Client Account management (invoices, statements by age, payments,
basic customer details)
Supplier management (basic supplier details, invoices, statements
by age, payments)
A secondary set of priorities would be:
Integration between Client/Supplier managament and accounting
Payroll management
Stocks mgt (warehouse, orders in and out)
VAT or equivalent
An alternative core set, which OFBiz seems to have been quite a
sucess at in terms of actual installations, is an ecommerce store
backed by limited stock management.
A manual which had a first section dealing with the above issues, a
second section dealing with setting up an ecommerce store, and a
third section dealing with tech issues (basic setup, how to make a
screen, and entity, a service, use the webtools etc), would be very
handy. My firm at least would buy a copy!!
As for who produces the manuals, I believe that the "centralized,
benevolent dictator" approach works better here than a free-for-all
Wiki. I reckon the best way to produce a core manual would be via
some kind of commercialized approach - the Pragmatic Programmers
managed to cover their costs and a wee bit more this way. Spring
also has excellent documentation and books available.
From the posts I have seen on this list, there are several core
committers who have the knowledge and explanatory ability to
produce a decent book, with the support of a technical writer.
What these people don't have is "quality time" to sit down and
write the fecker! And they never will unless you attach an income
stream to it.
cameron
----- Original Message ----
From: Jacopo Cappellato <[EMAIL PROTECTED]>
To: [email protected]
Sent: Thursday, 28 December, 2006 11:09:27 AM
Subject: Re: Community supported releases WAS [Re: Properly edited
OFBiz manuals]
David E Jones wrote:
I guess it depends on what the goal of doing a release is. In my mind
the goal should be to create (over time...) a stable set of artifacts
that people can build and deploy on if they choose not to go with the
latest/greatest.
What you're describing is interesting, but how is that any different
than just using the latest from SVN with a little timing based on
knowing what is going on added in, and keeping a list somewhere of
all
non-backwards compatible changes and their revision numbers?
Yes, you have described pretty well what I'm suggesting; I'd only
add to
these that we should also create the upgrade services (and/or upgrade
instructions) every time we commit a non-backwards compatible
change in
svn. As you said, this is not so different from what we are
(implicitly)
suggesting to do right now (as a best practice to stay up-to-date with
the trunk) but I think that it would be nice if the community will
officially support it for a few reasons:
1) it's often difficult for users to pick a 'stable' svn snapshot
2) it's often difficult for users to keep track of important changes
between their revision and the trunk
3) since it is not so different from what we are suggesting right now,
it will not add a huge cost maintaining these extra processes/releases
On that last bit, whatever we do with the releases having an official
wiki page with all non-backward-compatible changes listed on it
with the
revision number for each would be a good thing to do...
+1
But, back to the main point: what is the goal of a release in your
mind
(and in the mind of anyone else reading in too)?
I'd like to get the opinions from others too.
Personally I think that releases (or release instructions/plans)
should
at least help users to keep their system/data in sync with the main
trunk, minimizing the upgrade costs and simplifying the users'
decisions
(i.e. "should I upgrade now?").
Of course it would also be great to have a real 'stable' releases
(with
patches for them etc...) as you are suggesting (and I really think we
could implement the two approaches simultaneously since what I've
proposed could be the basis of a real release management) but I'm not
sure the community will really maintain them...
Jacopo
-David
Send instant messages to your online friends http://
uk.messenger.yahoo.com
