Ok, who's up for a software lifecycle and version
numbering schemes thesis? Maybe you can get a PhD out of it!
Jokes aside, the thing is that NO software release cycle is
perfect because various audiences seek different things.
FLOSS developers tend to prefer "release often, release
early" and "semantic versioning".
Perfectionists are going for "when it's ready" and "I only
need to increase one number since every release is just
perfect".
Traditional corporate vendors usually prefer "Rush it out
the door, we need it for yesterday, just try to hide defects
under the carpet and colorful design" and "We don't care, give
us the biggest number so marketing can show off".
Integrators and users want "Something with all the bells
and whistles that works out of the box, forever" and "No new
releases, they are a pain to deploy, so give me all the
features in this one".
To which I reply: "Not gonna happen!".
The current process is designed around the need to get code
out at a regular pace with some predictability to it.
It gives a version (N-2) supported roughly 1 and a half
year.
I don't think it's that great, but at least it's there!
IMO The Dolibarr project's lifecyle is missing some key
elements to achieve better releases quality before even
thinking about changing the release periodicity or version
numbering.
Here's a non exhaustive list from the top of my head:
- Standardized and enforced good commits content and
messages.
- Formal code reviews for everyone including the project
maintainers.
- Continuous integration used properly. Ie. no one can
bypass it. Ever.
- The previous two boils down to: no one pushes directly
to the main repository.
- Proper stabilization branches. One example of this is
git flow but other strategies are out there.
- Proper tagging. Having releases in the wild that do not
match the repository tags is a waste of everyone's time.
- Proper pre-release test cycle. With multiple alpha, beta
and RC releases. All properly advertised to get people
involved.
- Testing procedures and tooling.
- Automated building for all pre-releases.
- Formal testing both automated (Think unit tests,
selenium, test instances, fuzzing…) and manual.
- Final release should be exactly the same as the last RC.
- Long term commitment to lean toward modern coding
practices (refactoring, objectification, automate
everything…)
- Bugs bissecting to fix them at the root, not only in the
reported versions.
- Encourage unit tests for critical bug fixes to prevent
regressions.
- Community driven design before coding.
- …
As you can see, there's a lot of work and it can't be
done by any single individual. The whole community needs to
get involved.
But for that to happen, there should be a strong commitment
from the maintainers and core developers to stick to it and
make it happen.
We've already made some good progresses since switching to
GitHub.
Code is reviewed more often and bug reports are all
assessed and properly tagged (I devote some of my own time to
that weekly).
Keep in mind that all of that is a community effort, so the
best thing to do is step up to the plate, pick a task and do
something ;)
Looking forward to your contributions!