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
