search

Dolibarr / dolibarr

Dolibarr ERP CRM is a modern software package to manage your company or foundation's activity (contacts, suppliers, invoices, orders, stocks, agenda, accounting, ...). it's an open source Web application (written in PHP) designed for businesses of any sizes, foundations and freelancers.
https://www.dolibarr.org
GNU General Public License v3.0
5.46k stars 2.79k forks source link

Clearly state which versions of Dolibarr are supported on dolibarr.org/downloads.php and in the README.md #14416

Closed dpriskorn closed 2 years ago

dpriskorn commented 4 years ago

Bug

We should clearly state which version are supported and close all issues for deprecated versions.

I suggest we support the last 3 versions at most, that is v10, v11 and v12. This is actually already stated here in french: https://wiki.dolibarr.org/index.php/Versions

Environment

cfoellmann commented 4 years ago

I would suggest giving each version an EOL date (End-of-Life)

Maybe 2 years for a version after release of version X.0 . That resulting in a concrete date that can be added to the table on the pages mentioned above

cfoellmann commented 4 years ago

These EOL dates can also "send" a notification banner to admins in the dolibarr installation

dpriskorn commented 4 years ago

I do not agree that we should have EOL dates for the reason that we don't know when the next version is out and we really do not want to support more than 3 versions. Instead we could have a cron script that admins can enable to notify when the version is no longer supported.

eldy commented 4 years ago

Currently, we don't have "hard" reason to introduce end of life in a Dolibarr version. With no extra cost of work, due to a good organization of sources and the good tools, the project is currently able to guarantee that you can install a very old version, use it, and migrate to the last recent one, event if you wait 10 years before making your migration (Yes, migration from version released 10 years ago are still possible and guaranteed and this does not cost one penny for that because Dolibarr is "upgradable by design"). Since now 15 years, Roadmap is clear and never failed : There is 1 major version every 6 month, but you can amortize your project to deploy an ERP on 10 years if you want, migration will still be possible and be guaranteed. This is a very important pros.

A lot of project introduce end of life of version and manage Long Term Support version, but this is because they are not able to maintain all past branches. But the capacity of GIT, of our Continuous Integration system and our migration system allows us to be able to provide a maintenance version (a branch in GIT) for any past released version. So the choice to reduce the version or support to a very limited number of versions depends more on the integrator or the partner that you hire as your maintainer or support, than on the project itself. Adding restriction and forcing users to upgrade may be a good choice if it cost us a lot to maintain old versions, but the truth is that the cost of maintaining old versions is near 0. So each branch on Github is currently still opened. It is the contributions that the project receives (so the real usage on real life) that decides if a branch is still live or not. For end users this is better than forcing them to upgrades on a system on which they invested a lot to get the perfect processes and needs sometimes 4 or 5 years to be amortized (for large project of medium or very large companies for example).

dpriskorn commented 4 years ago

@eldy I love this feature as a business owner. Its a unique selling point that I urge you to state publicly. The only reason I recently upgraded from v9 was that I wanted more API endpoints that was added in more recent versions. Everything worked like a charm and compared to my experience with Odoo, bugs are very far between and customization like adding new extrafields is a breeze. 😀 Also the error messages are very clear compared to Odoo and I have a good idea about how the internals work just by looking at the error. Thats also rare. Often nowadays, programs have some framework that garbles errors and makes it hard to follow how the program ended up in the broken state.

cfoellmann commented 3 years ago

Maybe this can be closed. A wiki page for the handling of bug fixes in maintained branches would be nice