Time-based releases and love
I believe in time-based releases. I believe in frequent releases. I believe in a trunk branch that is always ready to be a release candidate. Many Free Software developers share my beliefs. For a long time I haven't questioned it. It's obviously good to release regularly and often.
"It is hard to argue that bzr isn't in a state of flux when a new stable version is available once a month." - Jason Earl, Bazaar mailing list.Now I think I have to begin asking questions.
Is it possible that time-based releases actually create negative impressions of software? Should regular releasers slow down their cadence? How should compatibility watersheds (format, API, whatever) affect a release cycle? What would Bazaar's format reputation be like if they released every six months instead of every month?
Labels: Bazaar
posted by jml @ 9:12 AM
6 Comments
6 Comments:
Please keep the monthly releases. It's quite nice to have the new features on a packaged format earlier. The developer are forced to keep the project in a "releasable" state more often too.
But I'd ask, *please*, don't add new default repository formats so often.
My proposal: do time-based *major* (2.0, 3.0, ...) releases too, every 6 months for example, and add a new default format only to this releases.
The new format, accumulating all backward incompatible changes, could be developed on a branch and integrated as a --development format when its good enough (like it is now), but only released as the default on a major release.
This way, distributions can offer always a bzr with the latest (or almost) format, and teams/hosting sites/sysadmins can get prepared to upgrade their repos less often.
I have to agree with Eduardo there. One of the reasons specifically cited by Brett Cannon today when discussing Python-on-hg is the number of changes to release formats in bzr.
I think that has way more of an impact on the impression of stability than does the frequency of releases; people just want to know it will always work wherever they happen to need some code, regardless of what version is installed there.
I don't see any reason to question the basic concept of always being ready to release, but that's not the same as releasing all the time. :-) Every month is good for a pre-1.0, after that, 3 or 6 months is a better pace to set. Being ready gives you the ability to do a critical bugfix release at the drop of a hat.
Also, If new formats had a big set of new features (instead of the one-format-per-new-feature-every-now-and-again like it is now), people would be more excited about upgrading. At least brisbane-core is something everybody will be really *really* excited about :)
I think bzr practive to release every 4 weeks is too frequent for the most users/admins. Once at 2 or 3 months is much better.
May be only point releases, e.g. 1.13.X should be released once at month.
E.g. for version X.Y.Z
Z = every month (only bugfixes)
Y = every 3 months (improvements)
X = every 9-12 months (big improvements, new formats)
My thoughts are not as specific as other commenters, but essentially: bzr does not provide any way to judge the level of change in its releases: the number is essentially 1.X where X is the number of months since 1.0 (give or take).
While Ubuntu also uses a similar strategy, most Free Software people really are accustomed to X.Y where a change in X means big changes including likely major fixes and improvements but also to beware of breakage, and a change in Y means tweaks to what you know, breakage unlikely. (For projects with dependant projects, X.Y.Z is better where a change in Z means no ABI/API break from the previous release, as required.)
Of course, one can get this from the release notes, but one doesn't read them...
@bialix: I think that point releases (especially when security fixes and fixes for major regression are involved) should be released any time if needed.
If bzr is to move to a longer release cycle (3 months, say), it can still do montly alpha/beta releases: an alpha on the end of the first month, a beta on the end of the second one (if no release critical bug id found, them is could slip some days), and a rc or two on the week before the final release.
Post a Comment
<< Home