I second all of that and would like to add a request that each new release
provides an automated installation procedure on MS Windows and one flavour
of Linux, say Ubuntu 6.06.
Kind regards,
Andrew Ballantine
-----Original Message-----
From: Cameron Smith [mailto:[EMAIL PROTECTED]
Sent: 29 December 2006 09:42
To: [email protected]
Subject: Re: Community supported releases WAS [Re: Properly edited OFBiz
manuals]
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
--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.432 / Virus Database: 268.16.2/613 - Release Date: 01/01/2007
14:50
--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.432 / Virus Database: 268.16.2/613 - Release Date: 01/01/2007
14:50
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.432 / Virus Database: 268.16.2/613 - Release Date: 01/01/2007
14:50
*****************************************************************
This email has been checked by the altohiway Mailcontroller Service
*****************************************************************
