Tuesday, October 11, 2011

Next Steps with LedgerSMB 1.3 and 1.4

Now that LedgerSMB 1.3 is released, it's worth looking at the next steps.

The first is to correct new bugs reported by users in this initial phase.  All issues deferred in 1.3.0 should be fixed in 1.3.1 unless something really urgent comes up.

The second is to get a few add-ons developed during 1.3 into a more production-worthy state.  These include addons for budgetting, and an improved trial balance module which should perform better on big databases and also  provides a number of enhanced features, such as the ability to run trial balances for a subset of accounts.

Following this, we hope to see the continued evolution of the 1.3 series through a variety of sources including community support.  This will happen during the development of the 1.4 series.

Some work has already been done on 1.4 including removing dependencies on the PostgreSQL contrib modules (replacing connectby() with WITH RECURSIVE common table expressions), and the beginnings of re-engineering the financial schema to be more SODA-like.  Of course these mean that PostgreSQL 8.4 will be the minimal version usable there.

A number of important framework changes will be made also including depending on Moose for new Perl code, and using a number of advanced PostgreSQL features including arrays of complex types, again in keeping with moving to 8.4 as the minimally required version.


  1. Good on you for requiring reasonably modern toolchains.

  2. David: As always it's a bit of a balance. As a policy we don't support Pg branches no longer available on PostgreSQL.org (which means no 8.1 support currently even though 1.3 *probably* runs there).

    When we started 1.3, Moose was also a bit immature, but it's since grown up.

    Also we will probably move our tests to PgTAP rather than using our home-built PostgreSQL->Perl test harnass framework.

  3. As an update all issues deferred in 1.3.0 except two very minor issues have been committed for 1.3.1. I have re-deferred these two because they require more intrusive changes than I am comfortable making in a short release cycle, and therefore will probably correct at least one of them immediately after 1.3.1 is released.

    This will allow for greater testing of these fixes for minor bugs than we can get if I commit them now.