ofbiz-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Sykes <and...@sykesdevelopment.com>
Subject RE: Community supported releases WAS [Re: Properly edited OFBiz manuals]
Date Wed, 03 Jan 2007 15:35:10 GMT

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:cameron_ord_smith@yahoo.co.uk]
> Sent: 29 December 2006 09:42
> To: ofbiz-user@incubator.apache.org
> 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 <tiz@sastau.it>
> To: ofbiz-user@incubator.apache.org
> 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 <andrew@sykesdevelopment.com>
Sykes Development Ltd

View raw message