== Packaging and installation ==
Both 1.4.30 and 1.5.0 have switched from 'Makefile.PL' dependency declaration to 'cpanfile' dependency declaration. Through this change, we now support enhanced application deployment through 'carton' (aka Perl's equivalent of ruby's 'bundler') as well as much simpler dependency installation, with no more chance to clobber a system beyond the ability to run parallel versions of LedgerSMB.
We have taken probably the last hurdle for the Docker images to *drop* their "EXPIREMENTAL" status (for 1.5): Although all document templates were stored in the database, any included documents (such as letterheads, headers or footers) were still loaded off the file system. In May, we implemented a change which now lets includes be transparently be loaded from the database.
For most 1.4 releases, the packages on
apt.ledgersmb.org have been succesfully updated.
Packaging for other distros: There was some activity on the development mailing list showing interest to work on a Gentoo package. Additionally, the project would love to be able to offer Fedora/RedHat packages. We currently don't have anybody working on this topic, but we have
rpm.ledgersmb.org or
repo.ledgersmb.org reserved for the purpose of hosting the result. Anybody with interest in starting this work, please step forward!
== Development progress ==
The during first half year of 2016, more than 300 pull requests were merged and more than 70 issues created and resolved.
A summary of achievements over the past half year:
* Test coverage jumped from 11 to 25% using the web-based testing
infrastructure (and increasing)
* (light) testing of appropriate formatting of SQL and HTML documents
* Discovered how to extract screenshots of failing browser-based tests from Travis CI
* 'cpanfile' dependency tracking for 'carton' style deployment
* Move to aggregated Dojo sources for great speed improvement loading pages
* Move the 'document root' from the project root to UI/ for better security and tree layout
* Moved away from 'Fixes.sql', the 1.4 way of deploying database changes;
should eliminate most output (noise: false failure reports) in the logs
* Multiple contributions to Test::BDD::Cucumber, including support for extensions,
to better support our testing use-cases
based testing code with other projects
* Adopted Test::Dependencies to ensure correct dependency setting
* Long list of 1.5 issues fixed
* Tremendously improved SQL Ledger 3.0 migration scripting
Some user-visible changes in the application:
* A single user account can now log in from different browsers at the same time
this fixes a regression from 1.3 (fixed in 1.4 and 1.5)
* Add a 'Create' button on the '
setup.pl' front page for new company creation
This change was directly based on user-feedback on the users mailing list
OpenHUB (
https://www.openhub.net/p/ledger-smb) still ranks us among the 0.3% highest activity open source projects. Additional stats: We have had 4 more contributors over the last 12 months than over the prior 12 months. The committers produced over this 12-month period, a total of almost 1'000 commits, doubling the number of the previous period.
Over the last half year, I've been spending a good portion of my time helping these new developers understand the code base so they can effectively and efficiently contribute.
In summary: development is really very active.
== 1.5 development/ release ==
Even though most of the development mentioned above already concerns 1.5, it seems to be fair to address it as its own category.
With the 1.5 release, we're doing things a bit differently than with prior releases: users have told us about 1.3 and 1.4 that installation was difficult and lacking documentation.
To prevent similar feedback about 1.5, we've written installation instructions and 'preparing first use' instructions on the
ledgersmb.org website *before* the release. A few users (but mostly John Locke) are testing their day-to-day scenarios with 1.5. When they hit problems, we fix those.
Additionally, the browser tests we're developing are at this point concentrated on the functionality that a first-time user is likely to hit. (Next to being directed at generating the highest coverage increases.)
The documentation has been written, most of the tests has been run through successfully. There are a quite a few test scenarios that remain to be written. Writing these scenarios stalled in light of the other two items and a highly needed rewrite of our testing framework. With the inception of Weasel, that has now happened (although inception of a new project never is the end of the work queue :-) ). All that means that the time has come to return to writing test scripts and the fixes to the bugs the tests may find.
While this means 1.5.0 isn't being released just yet, it does mean that when it will, it'll be our best-tested release ever. Also, even though 1.5 doesn't look all that different from 1.4, the UI works completely differently - impacting all screens, download and upload functionality. A change with impact this big needs to be thoroughly tested *and* is likely to slip -- we're working on it.
== Community interest ==
The FreeNode IRC channel (irc://
irc.freenode.net/#ledgersmb) is now bridged through Matrix and available through their Vector web client at
https://vector.im/beta/#/room/#ledgersmb:matrix.org . Attendance at the (now combined) channel has increased: we now have people active and around the channel for most of the 24h in a day and most weekdays (including weekends). Users are actively supported in their installation or usage problems.
On the users mailing list we saw great contributions from users discussing required features and much needed improvements, showing the very high commitment of our user base.
== Future direction ==
The new developers - some of whom 'had' to work on SQL Ledger in the past - have indicated that our code base - once they got used to it - is a relief to work on.
This reaffirms the premise of the longer developers that we're on the right track. A shortlist of items having been discussed:
* Is there a better templating engine than Template Toolkit?
We came to the conclusion that our template engine currently performs two roles:
1. Rendering our UI
2. Rendering our downloadable documents
While TT isn't fast, to perform (2), it doesn't really need to be.
With our move to run more code on the client side, our need for a template engine to do (1) will gradually decline. We might switch templating engines for (1) in the distant future if we need another one for that purpose.
* When can we start developing services?
In order to be able to take full advantage of Dojo, we *have* to start implementing services real soon now (i.e. quickly after we get 1.5.0 out the door)
* Is (La)TeX really our best option to generate PDF output in this day and age?
While *only* having LaTeX available for PDF output poses a needlessly high barrier of entry, with other options available including wkhtml2pdf (which supports a lot of CCS2+CSS3 for layout tweaking), we agree that the interest of our existing user base is best protected by continuation of the (La)TeX functionality. However, we're looking for resources to add wkhtml2pdf based PDF output in addition, in order to lower the barrier of entry.
* Is dojo really the best web framework we can build against?
While this is obviously a topic which lends itself for a hugel bikeshed debate, we have very good experience with Dojo so far. Angular prides itself with "no complicated DOM manipulation required", but to be honest, I'm not seeing any of that with Dojo either. As soon as one starts writing his/her own components, that's where the DOM fiddling starts; I can't see how Angular would prevent that. React boasts that it has much better templating support - while templating is important, at the size and complexity we're building our application, it's just a tiny piece of the puzzle. Also, people have plugged various different templating engines (Handlebars, React, dojox.DTL) into Dojo. I'm sure we can (re)use some of that work when the time comes we need to.
Where Dojo tries to stay 'out of the way' of developers by being non-opinionated, extensible in every respect, both Angular and React try to be exactly the opposite: reviews on the web state that e.g. Angular can't be combined with anything else (Do it the Angular way, or don't do it).
Concluding: the most solid, yet flexible solution which will support slow migration - one screen at a time - as well as a quick full-scale UI rewrite (moving parts of our UI functionality from the Perl request handlers to client-side JS), seems to be Dojo.
I hope I've given a comprehensive, yet summarized (I know, contradictio in terminis...) overview of what's all going on in the project.
If you have questions or feel like there are other efforts that need to be named, please follow up to this mail on the users list (
..hidden..).
Thanks for your attention!
--
Bye,
Erik.
Robust and Flexible. No vendor lock-in.