LedgerSMB

1.5.25 Released Security release No LedgerSMB_Team Sun, 08/18/2019 - 13:49 Release candidate No Download https://download.ledgersmb.org/f/Releases/1.5.25/ ... [More] 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.5.25 Fix regression when running in a schema other than 'public' (Erik H) Erik H is Erik Huelsmann For installation instructions and system requirements, seehttps://github.com/ledgersmb/LedgerSMB/blob/1.5.25/README.md The release can be downloaded from our download site athttps://download.ledgersmb.org/f/Releases/1.5.25 The release can be downloaded from GitHub athttps://github.com/ledgersmb/LedgerSMB/releases/tag/1.5.25 Or pulled from Docker Hub using the command $ docker pull ledgersmb/ledgersmb:1.5.25 These are the sha256 checksums of the uploaded files: 60bf5520a10f870d5c9f2b0ce620262f376fcc986011d6e00fc21ac6e8fd87a0 ledgersmb-1.5.25.tar.gz 369da04c42cb94888e48b4db3c41a2f376ae5fbd9695041bcfee14d7d3173eba ledgersmb-1.5.25.tar.gz.asc Release 1.5 [Less]

Table inheritance is one of the most misunderstood -- and powerful -- features of PostgreSQL.  With it, certain kinds of hard problems become easy.  While many folks who have been bitten by table inheritance tend to avoid the feature, this blog post ... [More] is intended to provide a framework for reasoning about when table inheritance is actually the right tool for the job.Table inheritance is, to be sure, a power tool and thus something to use only when it brings an overall reduction in complexity to the design.  Moreover the current documentation doesn't provide a lot of guidance regarding what the tool actually helps with and where are the performance costs and because inheritance sits orthogonal to relational design, working this out individually is very difficult.This blog post covers uses of table inheritance which simplify overall database design and are not addressed by declarative partitioning, because they are used in areas other than table partitioning.Table Inheritance ExplainedPostgreSQL provides the ability for tables to exist in an inheritance directed acyclic graph.  Columns provided by parent tables are merged in name and type into the child table.  Altering a parent table and adding a column thus cascades this operation to all child tables, though if any child table has a column with the same name and different type, the operation will fail.Inheritance, Tables, and TypesEvery table in PostgreSQL has a corresponding campsite type, and any table can be implicitly cast to any parent table.  This is transitive.  Combined with tuple processing functions, this gives you a number of very powerful ways of working with data at various different levels of scale.Indexes and foreign keys are not inherited.  Check constraints are inherited unless set to NO INHERIT.Inheritance and QueryingWhen a table is queried, by default all child tables are also queried and their results appended to the result.  Because of exclusion constraint processing, this takes out an ACCESS SHARE lock on all child tables at planning time.  All rows are cast back to the type of the table target (in other words you get the columns of the table you queried).Comparison to Java InterfacesDespite the name, the closest equivalent to table inheritance in other programming languages are Java Interfaces.  Here too you get implicit casts, a subset of fields, and a promise of compatible interfaces. And as a Java class can implement multiple interfaces, multiple inheritance in PostgreSQL is supported.  Java programmers are encouraged to think of inheriting tables in interface rather than inheritance terms.Use in Database Management DesignWhen we design a database there are often two overlapping concerns.  The first is in relational algebra operations on the data, and the second is in managing the data.  In a purely relational model this breaks down.Notes TablesOne of the first really productive uses of table inheritance I had was in the notes tables in LedgerSMB.  There are several hundred table in the database, and we want to attach notes to some subset of these tables.  A naive approach might be a single global notes table with a bunch of foreign keys, or an ambiguous foreign key, or we just have a bunch of completely independent notes tables.  All of these have serious obvious problems however.  Large numbers of sparse foreign keys provide tons of NULL-handling problems, and provide a wide table that is harder to reason about.  Ambiguous foreign keys are a terrible anti pattern which should never be used due to data consistency problems, and large numbers of independent tables provide an opportunity for subtle errors due to knowledge management problems.A slightly better solution might be to define a notes composite type, and use CREATE TABLE OF TYPE instead.  However typed tables of this sort have completely immutable schemas which makes them harder to manage over time.We can then define a table structure something like as follows:create table notes (    id serial primary key,    created_at timestamp not null default now(),    created_by text not null,    subject text not null,    body text not null,    fkey int not null,    check (false) NO INHERIT);This table will never have any rows, but child tables can have rows.  For child tables, creating them is now easy:create table invoice_notes (    LIKE notes INCLUDING ALL,    foreign key fkey REFERENCES invoice(id),) INHERITS (notes);The LIKE ... INCLUDING ALL indicates that we will copy in defaults, primary keys, and index definitions.  This now provides a forward-looking way of managing all notes tables going forward.  Uniqueness criteria remains enforced on a per-table basis.If I later want to add a materialization of a column using a function I can do that in a reasonably straight-forward manner, at least compared to alternative approaches.However, that's not all I can do.  I can then provide a search_terms function on the parent table which can be used to query child tables.create or replace function search_terms(notes)returns tsvector language sql immutable as$$select to_tsvector($1.subject) || to_tsvector($1.body);$$;I could then index, using GIN, the output of this function.  I still have to create the index on all current tables but if I index it now on the notes table, all tables I create with LIKE notes INCLUDING ALL will now have that index too. The function itself can be queried in a number of ways:select * from invoice_notes n  where plainto_tsvector('something') @@ search_terms(n);-- or select * from invoice_notes n   where plainto_tsvector('something') @@ n.search_terms; Once the function is created, that query works out of the box even though I never created a corresponding function for the invoice_notes table type.  Thus providing a consistent interface to a group of tables is an area where table inheritance can help clear out a lot of complexity very fast. Benefits include a more robust database design, more easily re-used human knowledge in how pieces fit together, and easier management of database schemas.Note on Use in Set/Superset ModelingThere are a number of cases where the query implications of inheritance are more important.  This area is typically tricky because it often involves multiple inheritance and therefore there are a number of additional concerns that quickly crop up, though these have well-defined solutions discussed below.Imagine we have an analytics database with numbers of pre-aggregated over possibly overlapping sets.  We want to sum up numbers quickly and easily without complicating the query language.  One option would be to create multiple views over a base table which includes the superset, but if your bulk operations primarily work over discrete subsets, you might get more out of breaking these out into subset tables which inherit the larger sets into which they are members.  This is, in effect, a reverse partitioning scheme where a single physical table shows up in multiple query tables.In certain cases this can be easier to manage than a single large table with multiple views selecting portions of that view.  Use of this technique requires weighing different kinds of complexity and is best left for other posts.Managing Schema Changes with Multiple InheritanceIn cases where multiple inheritance is used, adding and removing columns is relatively straight-forward, but altering existing tables can result in cases where an alteration interferes with checks on the other parent.  Renaming columns or changing types of columns is particularly tricky.  In most cases where this happens, a type change will not be done because rewriting tables is prohibitive, but renaming columns becomes the substitute and that is no less of a headache.The key problem to note here is that the problem is that you have to make sure that both parents are changed at the same time, in the same statement.    So the solution here is to create a super parent table with the subset of columns to be acted on, and then drop it when done.   So here we:begin;create table to_modify (id int, new_id bigint);alter table first_parent inherit to_modify;alter table second_parent inherit to_modify;alter table to_modify rename id to old_id;alter table to_modify rename new_id to id;commit;The changes will then cascade down the inheritance graph properly.ConclusionsTable inheritance is a surprisingly awesome feature in PostgreSQL, but misuse has given it a bad reputation.  There are many cases where it simplifies operation and long-term management of the database in cases where partitioning actually doesn't work that well.  This is a feature I expect to try to improve over time and hope others find it useful too, but to start we need to start using it for what it is good for, not the areas it falls short. [Less]

Table inheritance is one of the most misunderstood -- and powerful -- features of PostgreSQL.  With it, certain kinds of hard problems become easy.  While many folks who have been bitten by table inheritance tend to avoid the feature, this blog post ... [More] is intended to provide a framework for reasoning about when table inheritance is actually the right tool for the job.Table inheritance is, to be sure, a power tool and thus something to use only when it brings an overall reduction in complexity to the design.  Moreover the current documentation doesn't provide a lot of guidance regarding what the tool actually helps with and where are the performance costs and because inheritance sits orthogonal to relational design, working this out individually is very difficult.This blog post covers uses of table inheritance which simplify overall database design and are not addressed by declarative partitioning, because they are used in areas other than table partitioning.Table Inheritance ExplainedPostgreSQL provides the ability for tables to exist in an inheritance directed acyclic graph.  Columns provided by parent tables are merged in name and type into the child table.  Altering a parent table and adding a column thus cascades this operation to all child tables, though if any child table has a column with the same name and different type, the operation will fail.Inheritance, Tables, and TypesEvery table in PostgreSQL has a corresponding campsite type, and any table can be implicitly cast to any parent table.  This is transitive.  Combined with tuple processing functions, this gives you a number of very powerful ways of working with data at various different levels of scale.Indexes and foreign keys are not inherited.  Check constraints are inherited unless set to NO INHERIT.Inheritance and QueryingWhen a table is queried, by default all child tables are also queried and their results appended to the result.  Because of exclusion constraint processing, this takes out an ACCESS SHARE lock on all child tables at planning time.  All rows are cast back to the type of the table target (in other words you get the columns of the table you queried).Comparison to Java InterfacesDespite the name, the closest equivalent to table inheritance in other programming languages are Java Interfaces.  Here too you get implicit casts, a subset of fields, and a promise of compatible interfaces. And as a Java class can implement multiple interfaces, multiple inheritance in PostgreSQL is supported.  Java programmers are encouraged to think of inheriting tables in interface rather than inheritance terms.Use in Database Management DesignWhen we design a database there are often two overlapping concerns.  The first is in relational algebra operations on the data, and the second is in managing the data.  In a purely relational model this breaks down.Notes TablesOne of the first really productive uses of table inheritance I had was in the notes tables in LedgerSMB.  There are several hundred table in the database, and we want to attach notes to some subset of these tables.  A naive approach might be a single global notes table with a bunch of foreign keys, or an ambiguous foreign key, or we just have a bunch of completely independent notes tables.  All of these have serious obvious problems however.  Large numbers of sparse foreign keys provide tons of NULL-handling problems, and provide a wide table that is harder to reason about.  Ambiguous foreign keys are a terrible anti pattern which should never be used due to data consistency problems, and large numbers of independent tables provide an opportunity for subtle errors due to knowledge management problems.A slightly better solution might be to define a notes composite type, and use CREATE TABLE OF TYPE instead.  However typed tables of this sort have completely immutable schemas which makes them harder to manage over time.We can then define a table structure something like as follows:create table notes (    id serial primary key,    created_at timestamp not null default now(),    created_by text not null,    subject text not null,    body text not null,    fkey int not null,    check (false) NO INHERIT);This table will never have any rows, but child tables can have rows.  For child tables, creating them is now easy:create table invoice_notes (    LIKE notes INCLUDING INDEXES,    foreign key fkey REFERENCES invoice(id),) INHERITS (notes);The LIKE ... INCLUDING ALL indicates that we will copy in defaults, primary keys, and index definitions.  This now provides a forward-looking way of managing all notes tables going forward.  Uniqueness criteria remains enforced on a per-table basis.If I later want to add a materialization of a column using a function I can do that in a reasonably straight-forward manner, at least compared to alternative approaches.However, that's not all I can do.  I can then provide a search_terms function on the parent table which can be used to query child tables.create or replace function search_terms(notes)returns tsvector language sql immutable as$$select to_tsvector($1.subject) || to_tsvector($1.body);$$;I could then index, using GIN, the output of this function.  I still have to create the index on all current tables but if I index it now on the notes table, all tables I create with LIKE notes INCLUDING ALL will now have that index too. The function itself can be queried in a number of ways:select * from invoice_notes n  where plainto_tsvector('something') @@ search_terms(n);-- or select * from invoice_notes n   where plainto_tsvector('something') @@ n.search_terms; Once the function is created, that query works out of the box even though I never created a corresponding function for the invoice_notes table type.  Thus providing a consistent interface to a group of tables is an area where table inheritance can help clear out a lot of complexity very fast. Benefits include a more robust database design, more easily re-used human knowledge in how pieces fit together, and easier management of database schemas.Note on Use in Set/Superset ModelingThere are a number of cases where the query implications of inheritance are more important.  This area is typically tricky because it often involves multiple inheritance and therefore there are a number of additional concerns that quickly crop up, though these have well-defined solutions discussed below.Imagine we have an analytics database with numbers of pre-aggregated over possibly overlapping sets.  We want to sum up numbers quickly and easily without complicating the query language.  One option would be to create multiple views over a base table which includes the superset, but if your bulk operations primarily work over discrete subsets, you might get more out of breaking these out into subset tables which inherit the larger sets into which they are members.  This is, in effect, a reverse partitioning scheme where a single physical table shows up in multiple query tables.In certain cases this can be easier to manage than a single large table with multiple views selecting portions of that view.  Use of this technique requires weighing different kinds of complexity and is best left for other posts.Managing Schema Changes with Multiple InheritanceIn cases where multiple inheritance is used, adding and removing columns is relatively straight-forward, but altering existing tables can result in cases where an alteration interferes with checks on the other parent.  Renaming columns or changing types of columns is particularly tricky.  In most cases where this happens, a type change will not be done because rewriting tables is prohibitive, but renaming columns becomes the substitute and that is no less of a headache.The key problem to note here is that the problem is that you have to make sure that both parents are changed at the same time, in the same statement.    So the solution here is to create a super parent table with the subset of columns to be acted on, and then drop it when done.   So here we:begin;create table to_modify (id int, new_id bigint);alter table first_parent inherit to_modify;alter table second_parent inherit to_modify;alter table to_modify rename id to old_id;alter table to_modify rename new_id to id;commit;The changes will then cascade down the inheritance graph properly.ConclusionsTable inheritance is a surprisingly awesome feature in PostgreSQL, but misuse has given it a bad reputation.  There are many cases where it simplifies operation and long-term management of the database in cases where partitioning actually doesn't work that well.  This is a feature I expect to try to improve over time and hope others find it useful too, but to start we need to start using it for what it is good for, not the areas it falls short. [Less]

1.6.10 Released Security release No LedgerSMB_Team Sun, 01/20/2019 - 07:37 Release candidate No Download https://download.ledgersmb.org/f/Releases/1.6.10/ ... [More] 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.6.10 Apply correct layout to schema upgrade pages in setup.pl (Erik H) Fix iteration over row data provided in schema data fixes in setup.pl (Erik H) Fix schema upgrade with multiple failing checks looping infinitely (Erik H) Improve wording of correction instructions of schema check failure (Nick P) Respect tempdir when rendering ODS template (don't use current dir) (Nick P) Add user feedback when invoice needs recalculation before posting (Erik H) Erik H is Erik Huelsmann Nick P is Nick Prater For installation instructions and system requirements, seehttps://github.com/ledgersmb/LedgerSMB/blob/1.6.10/README.md The release can be downloaded from our download site athttps://download.ledgersmb.org/f/Releases/1.6.10 The release can be downloaded from GitHub athttps://github.com/ledgersmb/LedgerSMB/releases/tag/1.6.10 Or pulled from Docker Hub using the command $ docker pull ledgersmb/ledgersmb:1.6.10 These are the sha256 checksums of the uploaded files: 4028fcd2fd63d90988f031de013b81c4a11fe55b8908114e4c05f142ce6389a0 ledgersmb-1.6.10.tar.gz 071c780fc5d8e5b95f7009a86de8496a705e45496d3d9428bc7db25693244e26 ledgersmb-1.6.10.tar.gz.asc Release 1.6 [Less]

1.6.10 Released Security release No LedgerSMB_Team Sun, 01/20/2019 - 07:37 Release candidate No Download https://download.ledgersmb.org/f/Releases/1.6.10/ ... [More] 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.6.10 Apply correct layout to schema upgrade pages in setup.pl (Erik H) Fix iteration over row data provided in schema data fixes in setup.pl (Erik H) Fix schema upgrade with multiple failing checks looping infinitely (Erik H) Improve wording of correction instructions of schema check failure (Nick P) Respect tempdir when rendering ODS template (don't use current dir) (Nick P) Add user feedback when invoice needs recalculation before posting (Erik H) Erik H is Erik Huelsmann Nick P is Nick Prater For installation instructions and system requirements, seehttps://github.com/ledgersmb/LedgerSMB/blob/1.6.10/README.md The release can be downloaded from our download site athttps://download.ledgersmb.org/f/Releases/1.6.10 The release can be downloaded from GitHub athttps://github.com/ledgersmb/LedgerSMB/releases/tag/1.6.10 Or pulled from Docker Hub using the command $ docker pull ledgersmb/ledgersmb:1.6.10 These are the sha256 checksums of the uploaded files: 4028fcd2fd63d90988f031de013b81c4a11fe55b8908114e4c05f142ce6389a0 ledgersmb-1.6.10.tar.gz 071c780fc5d8e5b95f7009a86de8496a705e45496d3d9428bc7db25693244e26 ledgersmb-1.6.10.tar.gz.asc Release 1.6 [Less]

1.6.9 Released Security release No LedgerSMB_Team Wed, 12/26/2018 - 03:30 Release candidate No Download https://download.ledgersmb.org/f/Releases/1.6.9/ ... [More] The LedgerSMB development team is happy to announce yet another new version of its open source ERP and accounting application. Please note that this version fixes an bug where unsuspecting users could make accounting mistakes: sales taxes not correctly included in the amount due for purchase invoices. The bug is present in all 1.5 version prior to 1.5.24 and all 1.6 releases prior to 1.6.9. Also note that AP Transactions are not affected by this bug and have been working correctly in 1.5 and 1.6 releases. This release contains the following fixes and improvements: Changelog for 1.6.9 Fix all addresses selected on AR/AP Invoice's Ship To screen (Erik H, #3940) Fix sales tax not included in amount due on purchase invoice (Erik H, #3941) Fix selected sales person not showing correctly on AR Invoice (Erik H, #3949) Fix invoice selected shipping address not showing as selected (Erik H, #3899) Erik H is Erik Huelsmann For installation instructions and system requirements, seehttps://github.com/ledgersmb/LedgerSMB/blob/1.6.9/README.md The release can be downloaded from our download site athttps://download.ledgersmb.org/f/Releases/1.6.9 The release can be downloaded from GitHub athttps://github.com/ledgersmb/LedgerSMB/releases/tag/1.6.9 Or pulled from Docker Hub using the command $ docker pull ledgersmb/ledgersmb:1.6.9 These are the sha256 checksums of the uploaded files: 506aa3457d8b14eb2a2f55220c87f424e8dc52647469f781cf91a26ce6f41fb2 ledgersmb-1.6.9.tar.gz 50e93233f89de59fe236790ea20e49e1612642cf737d7bb6849be1b475d50a23 ledgersmb-1.6.9.tar.gz.asc Release 1.6 [Less]

1.6.9 Released Security release No LedgerSMB_Team Wed, 12/26/2018 - 03:30 Release candidate No Download https://download.ledgersmb.org/f/Releases/1.6.9/ ... [More] The LedgerSMB development team is happy to announce yet another new version of its open source ERP and accounting application. Please note that this version fixes an bug where unsuspecting users could make accounting mistakes: sales taxes not correctly included in the amount due for purchase invoices. The bug is present in all 1.5 version prior to 1.5.24 and all 1.6 releases prior to 1.6.9. Also note that AP Transactions are not affected by this bug and have been working correctly in 1.5 and 1.6 releases. This release contains the following fixes and improvements: Changelog for 1.6.9 Fix all addresses selected on AR/AP Invoice's Ship To screen (Erik H, #3940) Fix sales tax not included in amount due on purchase invoice (Erik H, #3941) Fix selected sales person not showing correctly on AR Invoice (Erik H, #3949) Fix invoice selected shipping address not showing as selected (Erik H, #3899) Erik H is Erik Huelsmann For installation instructions and system requirements, seehttps://github.com/ledgersmb/LedgerSMB/blob/1.6.9/README.md The release can be downloaded from our download site athttps://download.ledgersmb.org/f/Releases/1.6.9 The release can be downloaded from GitHub athttps://github.com/ledgersmb/LedgerSMB/releases/tag/1.6.9 Or pulled from Docker Hub using the command $ docker pull ledgersmb/ledgersmb:1.6.9 These are the sha256 checksums of the uploaded files: 506aa3457d8b14eb2a2f55220c87f424e8dc52647469f781cf91a26ce6f41fb2 ledgersmb-1.6.9.tar.gz 50e93233f89de59fe236790ea20e49e1612642cf737d7bb6849be1b475d50a23 ledgersmb-1.6.9.tar.gz.asc Release 1.6 [Less]

1.5.24 Released Security release No LedgerSMB_Team Wed, 12/26/2018 - 03:26 Release candidate No Download https://download.ledgersmb.org/f/Releases/1.5.24/ ... [More] The LedgerSMB development team is happy to announce yet another new version of its open source ERP and accounting application. Please note that this version fixes an bug where unsuspecting users could make accounting mistakes: sales taxes not correctly included in the amount due for purchase invoices. The bug is present in all 1.5 version prior to 1.5.24. Also note that AP Transactions are not affected by this bug and have been working correctly in 1.5 releases. This release contains the following fixes and improvements: Changelog for 1.5.24 Fix all addresses selected on AR/AP Invoice's Ship To screen (Erik H, #3940) Fix sales tax not included in amount due on purchase invoice (Erik H, #3941) Fix selected sales person not showing correctly on AR Invoice (Erik H, #3949) Fix invoice selected shipping address not showing as selected (Erik H, #3899) Erik H is Erik Huelsmann For installation instructions and system requirements, seehttps://github.com/ledgersmb/LedgerSMB/blob/1.5.24/README.md The release can be downloaded from our download site athttps://download.ledgersmb.org/f/Releases/1.5.24 The release can be downloaded from GitHub athttps://github.com/ledgersmb/LedgerSMB/releases/tag/1.5.24 Or pulled from Docker Hub using the command $ docker pull ledgersmb/ledgersmb:1.5.24 These are the sha256 checksums of the uploaded files: 1c9c54a707b1404c4296eec4cf7eda364caf11928d56c96ad3f2fd6da1a67563 ledgersmb-1.5.24.tar.gz 778244fe73db36ccb8fd5b6217c29e909807544cef226c290cb2d7de9e347451 ledgersmb-1.5.24.tar.gz.asc Release 1.5 [Less]

1.5.24 Released Security release No LedgerSMB_Team Wed, 12/26/2018 - 03:26 Release candidate No Download https://download.ledgersmb.org/f/Releases/1.5.24/ ... [More] The LedgerSMB development team is happy to announce yet another new version of its open source ERP and accounting application. Please note that this version fixes an bug where unsuspecting users could make accounting mistakes: sales taxes not correctly included in the amount due for purchase invoices. The bug is present in all 1.5 version prior to 1.5.24. Also note that AP Transactions are not affected by this bug and have been working correctly in 1.5 releases. This release contains the following fixes and improvements: Changelog for 1.5.24 Fix all addresses selected on AR/AP Invoice's Ship To screen (Erik H, #3940) Fix sales tax not included in amount due on purchase invoice (Erik H, #3941) Fix selected sales person not showing correctly on AR Invoice (Erik H, #3949) Fix invoice selected shipping address not showing as selected (Erik H, #3899) Erik H is Erik Huelsmann For installation instructions and system requirements, seehttps://github.com/ledgersmb/LedgerSMB/blob/1.5.24/README.md The release can be downloaded from our download site athttps://download.ledgersmb.org/f/Releases/1.5.24 The release can be downloaded from GitHub athttps://github.com/ledgersmb/LedgerSMB/releases/tag/1.5.24 Or pulled from Docker Hub using the command $ docker pull ledgersmb/ledgersmb:1.5.24 These are the sha256 checksums of the uploaded files: 1c9c54a707b1404c4296eec4cf7eda364caf11928d56c96ad3f2fd6da1a67563 ledgersmb-1.5.24.tar.gz 778244fe73db36ccb8fd5b6217c29e909807544cef226c290cb2d7de9e347451 ledgersmb-1.5.24.tar.gz.asc Release 1.5 [Less]

Year overview 2018 Here's my continuing the tradition to write about the state of the project on each year end. == Community interest == With the growth of the number of places to obtain LedgerSMB, it's becoming increasingly more ... [More] difficult to estimate the project popularity. We're now available through at least the following channels: Distribution packages (Debian repository, Ubuntu ppa, our own Debian/Ubuntu repository), Docker images on Docker Hub (with docker-compose support), regular 'tar file' download through GitHub or our own download site. Many of these sources don't track stats for hits, or at least those stats aren't available to us. A notable fact though is that the Google and Yahoo searches 'open source accounting' serve as the top hits a number of pages which cite or refer to LedgerSMB. Based on the steady stream of issues being logged on our GitHub issue tracker, the fact that the number of forks and stars (as well as watches) are steadily growing and the number of Docker Hub downloads is steadily increasing, I'd say that we get a fair amount of attention and our community is continuing to find people interested. == Releases == Last year's community overview looked forward to 2018 and expressed the hope to release LedgerSMB 1.6 in the first half of the year. And we did: June 10th we released 1.6.0 -- little less than a 18 months after 1.5.0! As expected, we were able to further shorten the time between releases. This year, we haven't topped last year's 20 releases. With 20 releases, the year can definitely be called succesfull though. We released: 10 stable releases: 1.6.0 - 1.6.9 10 old-stable releases: 1.5.15 - 1.5.24 Releases hardly ever contain fixes for regressions anymore. That's to say, regressions for functionality that worked in a recent release. Regressions being fixed went back to functionality being broken before 1.5.0 and sometimes even during the 1.3 or earlier release cycles(!). In addition to the 18 releases, significant new infrastructure landed on the master branch which helps advance the project to higher levels. An excerpt of all the work done includes further extension of the testing framework, separation of the template frameworks for UI and 'printed' materials and lots of minor and major code cleanups. In addition to generating releases, each year some effort is spent on release engineering; this year, we further automated the release announcements by automatically posting the news updates on github.com and ledgersmb.org (using the same announcement text as is used for the mail announcements). == Packaging and installation == The Debian+Ubuntu packages now include a new 'ledgersmb-1.6' package. The packaging process keeps improving, because by the end of the year, new packages were announced within 24 hours after the release of the new LedgerSMB version. With the introduction of the LedgerSMB 1.6 Docker builds, further energy was spent in shrinking the images. We started the year with images around 250MB in size (reported by Docker Hub); by the end of this year, images for 1.6 are showing less than 180MB and those for 1.5 around 160MB in size. That's another significant reduction. == Development progress == Over the course of 2018, 107 issues were created, of which 35 remain open at the end of the year (of which 8 enhancements); 126 issues were closed. More than 470 pull requests were created and 479 were closed. These numbers are significantly lower than last year, which is probably due to lower development activity (especially in the master branch) over the course of the second half year. However, the general feeling is that we are also continuing the trend of last year: due to the fact that the code base is increasingly more stable, there's more time to work on the more involved projects: those that (prepare to) refactor the code base. This work, while necessary, doesn't immediately produce commits or PRs. Last year, we set aside the code that we want to part with in the source tree, signalling to (potential) contributors which parts need improvement and which need replacement. Consensus has it that this distinction has lowered the barrier of entry by offering a relatively clean code base to newbee developers and this has in fact been a reason for this some of the activity of this year's contributors. In 2018, we ran over 1250 builds (starting at 6091; currently at 7354 and counting), but more importantly, we increased our test coverage from 27.48% to a current coverage of 34.22% (thanks Travis CI for all the donated compute time and Coveralls for the stats and analysis interface!). While we definitely have more code to cover to get to an acceptable coverage level, this is a very welcome increase! Areas which received extensive attention beyond that which has already been published through the 1.6 release notes include: work to explore the benefits of moving our code base to Dancer2 work to identify the roadmap to merging the MC (multi-currency) branch, including work to re-implementing some of the changes on the branch to adopt new paradigms as on 'master' implement checks, balances and tools to help people migrate their data to MC on upgrade work to de-couple frontend and backend implementations, even before there is a web API work to explore what needs to be done to support a REST API == New functionality and improvements == This year we added relatively little truely new functionality to the code base. Most effort was spent improving it. One thing worth mentioning in this area is the fact that we added tests to assert that modules (at the very least those we intend to keep) comply with a minimum level of documentation -- we set the documentation standard through Perl::Critic rules and we'll work toward increasing the standard over the next year, most likely. == Looking forward to 2019 == Ideally, we'll see the 1.7 release in the first half of 2019: that would shorten our release cycle to the much-desired yearly interval. Releasing by the end of the first half year puts businesses in a good position to test the software before running the year-end figures (assuming most businesses do so by the end of the calendar year). This year will likely be the year to land the MC branch effort on master, too. A lot of work has gone into preparation for this step and more work - following a precise checklist - is under way. Wether this functionality lands before 1.7 or after, is yet to be decided. Stability comes before anything else and we don't want to break our upward trend in that area. (Although some instability is to be expected after a subject this big lands on master, I'd like to have it stabilized before release.) For 2019, I wish the project finds one or two new contributors and our community has the patience to wait for MC to land before we continue into (also) highly desired areas such as a REST API -- to help the project to focus, that is. Then, lastly, let me finish by wishing everybody in our community a very good 2019 and by stressing that we'll welcome everybody who wants to contribute to our efforts (be it in development, testing, translating, documenting, coaching or sponsoring)!   ehu Mon, 12/24/2018 - 15:45 [Less]