Piwigo release cycle
Piwigo 2.2 was planned for Fall 2010. Obviously we have been late! Even if that doesn’t really matters, I would really like to shorten the release cycle. In my opinion, having less features is not a problem at all. Piwigo 2.1 was out on May 2010 and coding for Piwigo 2.2 really started in September (we made other useful stuffs than coding for 3 months).
Here is a review of past release cycles:
- 1.4 = 16 months
- 1.5 = 8 months
- 1.6 = 8 months
- 1.7 = 10 months
- 2.0 = 21 months. Far too long (with 6 months between RC1 and final version)
- 2.1 = 14 months. Better, but still too long.
- 2.2 = 11 months. Still Better, but can be improved.
Why is a long release cycle a problem? Because it encourages the coding team to add many new features at the very last moment (even after RC1) and to add nothing new right after the major release is available. If you have a short release cycle, there is no problem to say:
ok, let’s postpone this feature, I’ll add it for next major release
With a long release cycle, this would be:
oh no, if I don’t add this feature right now, I’ll have to wait another 10 months before it’s available in a stable release! let’s try to add it now and postpone the release date
The consequence is a release cycle becoming longer and longer.
A good compromise is a 6 month release cycle. There is no real problem as soon as we’re not forced to add a fixed list of features. Instead of a list of features, we set the release date, and we’ll have the stable features available that day (after a 1 month release candidate period RC1, RC2, RC3…). Piwigo 2.3 will probably have less new features than 2.1 or 2.2 but it doesn’t matters at all.