It's becoming a tradition for me to write about the state of the community and what has been going on in the project at this time of year. This will be the third time to look back over the past year and look into what the next could bring.

== Community interest ==

Last year, I expressed the hope and expectation that we'd be able to keep up the same speed of development. And while development progress has been good, we were not able to keep up with the current speed when measured in number of commits: the number of commits dropped significantly this year (as measured by OpenHUB). While the number here is probably skewed by the fact that only commits on the master branch are being counted (and thus commits on backport branches are discarded), there is probably some truth in these numbers.

One of the other expectations expressed was that with fewer regressions, more energy could be spent on progressing actual development, allowing for more thorough refactoring as well as resolving some of the longer-standing bugs. This is exactly what happened: the last few releases in the 1.4 stable series fixed many long-standing bugs and annoyances. The lower number of commits can in part be explained by this trend: with attention for refactoring and "ways forward", there's been a need to spend time discussing next steps more than there ever was before.

This year, same as last year, we've seen very high traffic in the LedgerSMB Matrix/FreeNode channel: the channel aggregates updates from GitHub, Travis CI and the ledgersmb.org site as well as facilitates discussion of every aspect of our community (from helping newbee users to discussing next steps on almost every aspect of the project).

Another part of the slowed development is the fact that this year was - for our project - the all-time low in our relationship with SourceForge. We felt we were forced to close our project on the site and move all of our (remaining) use of it elsewhere. Fortunately, with the help of various core committee members, we were able to quickly round up download and mailing list services. SourceForge didn't want to provide us with the list of mail addresses that were subscribed to our lists, meaning we unfortunately had to start our lists from scratch again.

== Releases ==

The project created 20 releases in 2017, meaning it matches 2016 in that respect:

• 14 stable releases: 1.5.1 through 1.5.14
• 6 oldstable releases: 1.4.37 through 1.4.42

The 1.4 branch has reached EOL (End-Of-Life) and will not see further maintenance releases from the community. In order to help those who are stuck with 1.4 for a little while longer, the project fixed many of the longer-standing problems in the last releases before the EOL date. [Note: Should you be unable to migrate to 1.5 yet are running into problems, one of the commercial support suppliers will be glad to help you; see https://ledgersmb.org/topic/commercial-support]

At the end of 2016, we agreed on a backport policy for new functionality, refactorings and any other changes that might not be low-impact. In 2017, we stuck to that policy, resulting in a very stable 1.5 experience so far.

This year we tightly integrated updating the LedgerSMB Docker images with the release of the source code tarball: now, when we a new release is generated (and announced), the Docker images will be ready for download as well.

== Packaging and installation ==

This year, the 'ledgersmb' package has been superseeded by two packages, one named 'ledgersmb-1.4' the other named 'ledgersmb-1.5'. These packages' naming resemblance to PostgreSQL isn't accidental: like the PostgreSQL packages, they are meant to be run side-by-side to facilitate the upgrade path from 1.4 to 1.5.

One thing to be very proud of in the area of packaging that we achieved this year: the size of the Docker images went down from original sizes 2.6+GB down to less than 250MB! This brings our images in line with what users would expect of a Docker images.

== Development progress ==

Starting off with some statistics: Over the course of the year, 262 new issues were created (out of which 73 were enhancements, 10 were "design trackers" -- issues to discuss the design of future solutions) and 162 issues were closed; 620 pull requests were created and 630 pull requests closed.

Sentiment is that the 1.5 release branch is doing well: issues being fixed are rather long standing problems inherited from 1.4 (or even 1.3) rather than regressions in the releases themselves. To that extent, the new backport policy proves useful in improving stable branch reliability. As a result, developers have been spending time working on the master branch more than in other years.

While the user experience work and JavaScript developer that we expressed in 2016 we hoped to do in 2017, didn't materialize, a lot of code clean-up has gone into the master branch in 2017 in a variety of areas:

• Removal of the need to have an 'Inventory Entity' (which used to be used for inventory adjustments)
• Removal of the need to write all PSGI responses to files before being served to the web
• Refactoring and code de-duplication in the template handling framework
• Elimination of warnings and notes from the database creation process
• Much stricter code checking using Perl::Critic
• ... and many many more ...

 

That said, there are still 5 issues considered blocking a 1.6 release (see the 1.6 milestone for more details). Last week we discussed how to approach these 5 blockers and "unblock" a release (which provides us with the option to release, not with the obligation!).

As for the "MC" (multi-currency) branches, the time to merge these to the master branch doesn't seem right before a 1.6 release as the destabilization effect is currently being estimated too high a risk. One of the 5 blocking issues for 1.6 is also blocking bringing MC to master: it must be possible to develop a smooth schema upgrade process in order to support the schema changes required for MC. However, such tooling isn't currently in place. By releasing 1.6 with such tooling, we'll be able to build up some experience with it before stretching its use by running the MC upgrades on it.

== New functionality and improvements ==

The most visible improvement in LedgerSMB itself is that inventory adjustments no longer need the inventory entity and that the adjustment process no longer generates invoices. The biggest improvements in the release process would be the integration of the Docker image.

Other improvements include the harmonization between the SQL Ledger migrations from 2.8 and 3.0 into LedgerSMB 1.5 -- these now use a single process with a few conditional steps, instead of two separately coded processes.

Last, but probably not least, we reorganized the source tree to set aside all code that we want to part with. As most of you will know, we have a part of the code base which is rather fragile. We want to remove that part of the code base by rewriting it. Until it's rewritten, we want to make sure it's touched as little as possible. Both goals are served by setting the code apart, by communicating clearly which code is slated for replacement.

== Looking forward to 2018 ==

Over the past releases, we have been able to shorten the release cycle, quickly releasing functional changes relevant to some instead of holding releases long until it had changes relevant to all. In that light, the first half of 2018 hopefully brings us 1.6, which would mean another significant shortening of the release cycle.

With a year of refactoring and stabilizing behind us and the more-than-1-year-old Pull Requests merged, the project is in a good position to finish some of our long-wanted projects as well as some items on the roadmap.

Let me finish by wishing everybody in our community a very good 2018 and expressing that we'll find a fitting role for everybody who wants to contribute to our efforts! Be it in development, testing, translating, documenting, helping others or sponsoring development!