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
- 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
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
<https://hub.docker.com/r/ledgersmb/ledgersmb/tags/> 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
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
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.
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 <https://github.com/ledgersmb/LedgerSMB/milestone/3> 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
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
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
== 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
<https://github.com/ledgersmb/LedgerSMB/projects> as well as some items on
the roadmap <https://ledgersmb.org/content/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!
-- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.