Andrew, Automated installs are probably a bad idea, because they assume you are just going to use OfBiz straight out of the box.
I am yet to come across anyone who uses OfBiz in this way unless it's a very small hobby project of the like. I'd encourage people to do their best to get to grips with some of the fundamentals of installing/modifying, the extra knowledge is worth its weight in gold! - Andrew (Sykes) On Tue, 2007-01-02 at 11:07 +0000, Andrew Ballantine wrote: > 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 > ***************************************************************** -- Kind Regards Andrew Sykes <[EMAIL PROTECTED]> Sykes Development Ltd http://www.sykesdevelopment.com
