Hi everyone,
Sorry I'm a little late to the party, i was taking vacations :D
Dolibarr release cycle is … well … a release cycle. There is no right or wrong way, only infinite possibilities in between.
What we should account for first, IMHO, is the size of the manpower we have driving the main development. Looking at the numbers (git shortlog -sne 3.6.0..develop) , we're not that much. I get 71 different committers (based on email addresses so a few dups). eldy being the main man (More than 50% of the commits kudos to him!) and second man being at a mere 8% (!). The core team is composed of 15 people at most. Numbers are pretty much the same for the previous cycle. But for maintenance release (git shortlog -sne 3.6.0..3.6), only 20 committers with again eldy almost hitting 50%.
This means two things:
- First, developers seem to have no interest in maintaining the code. So having longer integration periods will, as said eldy, only make things worse.
- Second, we don't have much resources so we must keep things as streamlined as possible and use them wisely.
I have a feeling that maintaining 3 versions (n, n-1 & n-2) is already a _huge_ effort.
Of course, we could use a LTS scheme but someone need to step up to spec and lead the project.
Although I very much like the idea, I'm not volunteering, I'm already unable to make a friggin' release (yeah, shame on me, but I spec'd it already).
I also like the "Release often, release early" mantra often used in free software communities so we should keep going.
Shifting the release dates may have some advantages for commercial users, I kind of like the idea but you can't make everybody happy.
Some things stroke me though:
- Updating looks like a pain for our users. Maybe it's time for some "Automatic" (read Assisted) upgrade mechanism. Could make a nice bounty, I'd certainly pay for that.
- Some bugs stay unfixed between versions. Maybe we should try putting up some events like "bug squashing day" or whatever, once a month with some nice rewards (Thanks email, a wiki and/or forum badge, a hug. Yeah, resources are pretty scarce these days but you get the idea) as an incentive to get developers and users interested in maintenance. (I'm guilty not being.)
- Updating breaks external modules. Well that's very unfortunate they're external… (Sorry, couldn't resist)
We can't guarantee a stable API without some heavy burden on our Yodas and I don't think they'd like it. Also, if you're a module developer, it's your responsibility to make the modifications needed in the integration period ! You're doing two things at once doing it there. Make sure your module works with the new Dolibarr and that Dolibarr is bug free on release. Does it sound nice or what. Also, unlike proprietary software, the code is available early so you really have no excuses. Incompatible changes are often very well documented in the ChangeLog. But feel free to contribute some core code that'll make your life easier (Better API, looser coupling, your module…).
Anyway, my 2 cents,