December 2021 - devel - lists.freelock.com

Bug#982109: ledgersmb: new upstream releases
by Chris Hofstaedtler 22 Jan '22

22 Jan '22

Source: ledgersmb Version: 1.6.9+ds-1 Severity: wishlist Hi, Upstream has made numerous new upstream releases since 1.6.9. From what I can tell there's an 1.8.x branch already. Please consider packaging new versions. Chris

3 3

LedgerSMB Community overview 2021
by Erik Huelsmann 27 Dec '21

27 Dec '21

As the year-end approaches, it's time to provide an overview of what our community has achieved over the past year. At the end of last year, I wished everybody a healthy and prosperous 2021. The year has turned out to be as challenging as the last and I hope this overview reaches you in a health as good as (or better than) last year's. == Community interest == Although the number of hits on the website has declined steadily over the years, it seems that the decrease is slowing down: ca 1,000 fewer hits than in 2020, but 2020 lost ca 6,000 hits when compared to 2019. Traffic on the mailing lists was - in line with 2020 - very low this year. However, from the fact that during the year, we've also seen the number of Stars and Forks on GitHub slowly but steadily increase (Stars went up from 207 on 22 December 2020 to 260 today), we can conclude that there is still interest in the project, however, the broader community didn't have much time to engage with the project this year -- similar to what other volunteer-driven projects are experiencing this year. == Releases == With the release of 1.9.0 on 25 September 2021, we realized our goal to release 1.9 in the second half of the year, around a year after 1.8. This way, our target of releasing around the middle of the year, in order for the software to mature well before year-end (when most companies close their books). Despite the short release cycle, we were able to include a sizeable list of new functionalities, changes and (code) cleanups through 902 files changed, 306,496 added lines and 271,066 removed lines of code (and comments) between 1.8.0 and 1.9.0. With the number of releases doubled in 2020 over 2019 (44 releases over ~20 before), the question was whether we'd keep it up to release that often. Turns out we were able to meet our prior year standards with 38 releases in 2021: 1.6 (5): 1.6.29 - 1.6.33 1.7 (12): 1.7.26 - 1.7.37 1.8 (15): 1.8.10 - 1.8.24 1.9 (6): 1.9.0 - 1.9.5 Which excludes the alpha, beta and release candidate releases. == Packaging and installation == For the 1.9 Docker images, we moved from Debian Buster to Debian Bullseye as the base operating system. Contrary to prior experience - moving to Buster - there were no notable problems in the move. Significant engineering effort went into automating the mapping of Perl dependencies to their Debian package names during the Docker build process. By having this automation in place, error margin and manual release maintenance has been eliminated. The automation worked so well that it was backported from the initial 1.9 implemenetation to the release processes for 1.8 and 1.7 as well. With some help from the Debian community, we were able to fix the packages that come with Debian Bullseye: the packages that were there before were missing the "old/lib/" subdirectory. Unfortunately, Debian still includes 1.6. == Development progress == This year saw fewer commits than last year. Although this could be an indication that our project is suffering from the same problem many other Open Source projects have during the pandemic: a loss of available time from their contributors. I don't think that's the case for our project as some of it can be explained by the tougher topics being picked up in the second half of the year. Although the sheer number of commits was lower, the number of pull requests (832) is in the same order of magnitude as those from last year. The number of active developers - judging by accepted commits - went up from 47 last year to 9 people contributing commits this year - even though 2 of last year's contributors were one-off contributions. Last year I expressed my desire to close a number of long-standing issues this year and in fact, we have: * #975: Edit/Update on a saved invoice or transaction clobbers changes * #1135: Ability to delete a login account * #816: Ability to install in a schema other than "public" * #835: Performance of the balance sheet report (should use cached balances) All from 2015, just to name a few. Project commits on all branches (excluding merges and bots): 895 Erik Huelsmann* 139 Yves Lavoie* 61 Aung Zaw Win* 11 Neil Tiffin* 4 Richard T. Weeks 3 NoGare 2 lianto.ruyang 2 daOrangePeeler 1 Xin Wang * includes contributions on maintenance branches By comparison, these are the figures for 2020: 1247 Erik Huelsmann* 179 Yves Lavoie* 108 Nick Prater* 37 Aung Zaw Win* 3 Håvard Sørli 1 Bobberty 1 Andreas Karlsson Please note that the number of commits is in no way a measure of time spent on the project. Also note that these numbers don't include the time spent by those taking the effort to report their problems and taking the time to respond to developer questions as well as helping to test solutions when developers think they solved the problem. Similarly, there was a lot of activity with respect to issues: Number of open issues at 2021-01-01: 226 of which remain open today: 137 Issues closed: 173 of which created before 2021-01-01: 89 Issues created: 105 of which still open: 21 Number of open issues today: 158 This amount of development activity triggers many CI/CD jobs. Last year, we had just moved our regular CI loads to GitHub Actions; this year we have run almost 2,000 CI workflows on the main repository alone(!). A high number of jobs was triggered by Dependabot and Renovate Bot, two bots which have helped us to keep our JavaScript dependencies up to date. While Dependabot could run integration checks multiple times a day, we moved to Renovate in order to be able to reduce the number of CI jobs and merges. They're now set to once a week -- we're not releasing multiple times per day from our repository anyway. In the Changelog for 1.10 (https://github.com/ledgersmb/LedgerSMB/blob/master/Changelog#L3), you'll be able to read where we spent our time, for all effort that didn't end up in 1.9 and wasn't listed above. Areas that we're currently spending time on, include: Encapsulating Dojo widgets in "custom elements" in order more easily switch component libraries Putting the requirements in place in order to develop our UI with Vue3 Development of webservice APIs The 158 issues that are open today summarize into these statistics: * 11 bite-sized: a good place to start when looking to make contributions * 69 enhancement: requesting new features added to the application * 4 help wanted: looking for someone to help out on this issue * 10 migration: these issues need help testing and developing migration from SQL Ledger * 6 needs-documentation: there's not enough documentation... (Note that an issue may fall into more than one category or none at all.) == New functionality and improvements == Distributed with 1.10, a very nice although somewhat niche, functionality was added supporting localized handling of taxes: in the US, Washington State (WA) operates a web service which serves the tax rate in the tax district. We have built a module that queries this service based on the billing address on the invoice. The module calculates the applicable tax amount and posts it. The webservice returns a "tax district code" which gets posted with the amount for tracking and auditing by an accountant. This use-case goes to show what customizations are becoming possible after the years LedgerSMB has been in development, with all the code cleanup that has been going on. == Looking forward to 2022 == In 2022, we'll likely release 1.10 around the middle of the year; again in a release cycle a bit shorter than a year. This year two release branches will reach End-Of-Life status: 1.8 on 4 September 2022 and 1.7 on 4 October 2022. By the end of 2022, we'll be back to supporting two active release branches as we were before we switched to yearly release cycles. Experience has shown that given sufficient automation, maintenance of 3 branches is doable, but still challenging; there are simply too many merge conflicts on any non-trivial backport to do the job well. And last but not least, I'm hoping for 1 or 2 new contributors (not necessarily developers; translators, testers, documentation writers or UI artists are all greatly appreciated!). If you want to contribute, but don't know where to start, please contact me. == In closing == Thanks to everybody who contributed to any of the above in any way, especially to Computerisms.ca for hosting our DNS Freelock.com for hosting our website and mailing lists Efficito.com for hosting our mailing list archive, apt repository, release and download server GitHub.com, CircleCI and coveralls.io for hosting our development workflow My special personal thanks go to my GitHub Sponsors for supporting me for time, efforts and (financial) resources dedicated to the project! Leaves me only to wish everybody in our community - and their loved ones - happy holidays and a safe and productive 2022! -- Bye, Erik. http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.

2 1

LedgerSMB 1.9.5 released
by Erik Huelsmann 08 Dec '21

08 Dec '21

The LedgerSMB development team is happy to announce yet another new version of its open source ERP and accounting application. This release contains the following fixes and improvements: Changelog for 1.9.5 * Fix correct AR/AP account being selected on Update and when editing (#6191) * On date-entry, add the separator character immediatly when possible (#6121) * Fix the end date on credit accounts being shown correctly (#6235) * Fix calculation of credit limit remaining shown on transactions and invoices * Fix credit limit remaining calculation for foreign currency transactions * Extend AR/AP batch import to support multi currency imports (#6250) * Fix login errors being hidden behind an "insecure response" error (#6251) * Fix deletion of unapproved batches failing (#6252) * Fix GL batch import menu item missing, even with appropriate permissions (#6248) For installation instructions and system requirements, see https://github.com/ledgersmb/LedgerSMB/blob/1.9.5/README.md The release can be downloaded from our download site at https://download.ledgersmb.org/f/Releases/1.9.5 The release can be downloaded from GitHub at https://github.com/ledgersmb/LedgerSMB/releases/tag/1.9.5 Or pulled from Docker Hub using the command $ docker pull ledgersmb/ledgersmb:1.9.5 These are the sha256 checksums of the uploaded files: 94d1fe61b5c5c2914c0f02bc57794754ae51cbd52efea115ff4a7bdc16bcee94 ledgersmb-1.9.5.tar.gz fcd0872685e3c112cfe19a915e8bf13189a733630ea67960211e27cebd153a87 ledgersmb-1.9.5.tar.gz.asc

1 0

LedgerSMB 1.8.24 released
by Erik Huelsmann 08 Dec '21

08 Dec '21

The LedgerSMB development team is happy to announce yet another new version of its open source ERP and accounting application. This release contains the following fixes and improvements: Changelog for 1.8.24 * Fix multiple issues with bank account reconciliation (#6122) * Fix correct AR/AP account being selected on Update and when editing (#6191) * Fix the end date on credit accounts being shown correctly (#6235) * Fix calculation of credit limit remaining shown on transactions and invoices * Fix credit limit remaining calculation for foreign currency transactions * Fix login errors being hidden behind an "insecure response" error (#6251) * Fix GL batch import menu item missing, even with appropriate permissions (#6248) For installation instructions and system requirements, see https://github.com/ledgersmb/LedgerSMB/blob/1.8.24/README.md The release can be downloaded from our download site at https://download.ledgersmb.org/f/Releases/1.8.24 The release can be downloaded from GitHub at https://github.com/ledgersmb/LedgerSMB/releases/tag/1.8.24 Or pulled from Docker Hub using the command $ docker pull ledgersmb/ledgersmb:1.8.24 These are the sha256 checksums of the uploaded files: 9fa485960be1a0c7500e60d2041380d494c84b542706e4fba3150b4c43657275 ledgersmb-1.8.24.tar.gz 1aafc72d4fe1ca161b6a0c3bbc00d299e4f1fb621774c37330d671493d528b16 ledgersmb-1.8.24.tar.gz.asc

1 0

LedgerSMB 1.7.37 released
by Erik Huelsmann 08 Dec '21

08 Dec '21

The LedgerSMB development team is happy to announce yet another new version of its open source ERP and accounting application. This release contains the following fixes and improvements: Changelog for 1.7.37 * Fix login errors being hidden behind an "insecure response" error (#6251) For installation instructions and system requirements, see https://github.com/ledgersmb/LedgerSMB/blob/1.7.37/README.md The release can be downloaded from our download site at https://download.ledgersmb.org/f/Releases/1.7.37 The release can be downloaded from GitHub at https://github.com/ledgersmb/LedgerSMB/releases/tag/1.7.37 Or pulled from Docker Hub using the command $ docker pull ledgersmb/ledgersmb:1.7.37 These are the sha256 checksums of the uploaded files: 4508200782fd5f39b4ac14521c80e0112f224c8db50581e2829e686c7555a82d ledgersmb-1.7.37.tar.gz db63bf9c2c3c3cfcf0ca87fbb2aa835a8c28322ee2f48d522fbbdb1a2e500624 ledgersmb-1.7.37.tar.gz.asc

1 0

What versions should I port in?
by Chris Bennett 05 Dec '21

05 Dec '21

I was wondering which versions I should try to port in. 1.7, 1.8, 1.9? Bringing in more than one version is OK, but what are people using the most? Which ones are approaching end of life/support? As far as the optional features, I can just leave a message after installation about being able to get those features afterwards by downloading the necessary packages. I can't do any testing at home. The amdgpu firmware hasn't worked out for my laptop. -- Regards, Chris Bennett

2 1

Once again going to try to port into OpenBSD. :-}
by Chris Bennett 05 Dec '21

05 Dec '21

Hello again! I found a nice Black Friday special on a server I can afford. So, another time, 4th time, but who's counting? As I suspected, I would hit a moment where I couldn't come up with $136 a month. So I had to drop that server. Same server, but $67 now. I saved my work on github, which is a big mess, but will help a lot. I learned a ton about submitting and how to deal with that set of Locale::CLDR modules. I also had a strange problem. As far as I have seen, nobody has ever done a project with dozens of dependencies to bring in as just a single person. These types of projects have always been done by groups or really top notch porters, with commit powers to the CVS repository. One problem I had was not seeing the obvious solution to how to deal with really long chains of new dependencies. The people who review submissions DO NOT want single ports to be submitted one at a time, because they are very busy. It didn't occur to me how to deal with this problem until after I stopped working on this. Rather than submit a ridiculously long set of 12 or more dependencies from the LedgerSMB cpanfile outwards, I needed to go out to the end of the chain and work inwards instead, thus submitting only 2-4 at a time. I am now starting up again. I would really appreciate any help, including just a little bit. Even getting just one Perl module ready to submit is more than enough. Different OS's have different goals. OpenBSD is primarily security oriented, so the method of getting a port ready is very strict. Building a port outside of the porting system is strictly forbidden. The FAQ's about porting and the man pages are a bit overwhelming, but most of the needed dependencies are pretty easy to work with. It does require running OpenBSD -current, but that has been amazingly good for quite some time. If you would either like to help or just tell me if you are wanting this to be done, please let me know. Just telling me you want this is really encouraging for me. My ugly mess is at https://github.com/CPBen/LSMB-for-OBSD-WIP It's so messy since I had to upload and download a few hundred GB to and from home and across two servers. Sorry. -- Regards, Chris Bennett

1 0