Time-based releases in open source
Whenever I hear someone saying we should have regular releases, I hear we should release when Venus enters Pisces. Because, when you have so many uncontrolled parameters to deal with, sticking to a predefined calendar boils down to superstition.
Time-based releases actually make sense in one case : when you're selling your software. That way, you can ensure a regular stream of revenue via upgrades. Moreover, if you're a commercial entity, you probably are already paying full-time a couple of developers, so you can predict how much time you'll spend on the next version during the next few months.
All those premises are not true for volunteer-based open source projects, such as Perl.
Actually, time-based releases still make sense if the project is in an alpha stage and is being prototyped. In this case, however, it's more accurate to speak about snapshots than releases, because such a "release" is only a way to publicize the newest changelog. That's the case for parrot, for example: it doesn't aim for backwards compatibility, or even stability, and has no user base. That would be also the case for the development branch of Perl 5 (currently 5.11), although nobody got around to do it since the migration to git -- I agree that would be a nice improvement.
In the specific case of Perl 5, even if you wanted to try to have regular releases, more factors would complicate the task. You can't release bleadperl at any point and call it stable, even when all dual-life modules are perfectly in sync with the CPAN and when all tests pass on all platforms and all configurations. That's because you also need, for a new major release, to have a consistent set of features. For example, it would not have made sense to release 5.10.0 with the lexical $_ variable, but without the (_) prototype.
With the upcoming release of 5.10.1 by Dave Mitchell, we're trying to improve the release process to be less of a pain for the pumpkings. Changes to dual-life modules will no longer be accepted in the core unless they are put on CPAN first. Module::Corelist will refer to tags in the git repository instead of perforce change numbers. The perldelta will hopefully be written a bit more incrementally.
I plan to copy 5.10.1's perldelta in bleadperl when it's done, then to supplement it by blead-only changes. Afterwards I'll have more elements to judge whether we're ready for a 5.12.0 or not -- and that decision will be motivated by the contents of the release, not by the time of the year.
8 comments:
To my eye, the disconnect appears to be about what goes into the time-based release. If you use time-based releases then you must use branches to separate the fully-baked features from the works-in-progress.
Using your example of prototype changes, that large feature would not hold up simple bug fixes if it were on a feature branch.
Like the time-based schedule used by Ubuntu or the Linux kernel, a Perl community time-based release would just include the stuff that was ready. In principal, the only additional overhead this would entail would be Git branch management (of course, I don't mean to trivialize that).
Hi Chris,
I think you're glossing over an important detail here: In a programming language, features are rarely independent. (Re $_ and _ prototype, for example)
Cheers,
Steffen
The interdependency of features is a straw man.
Even lexical $_ and the _ prototype are not mutually interdependent – the latter makes sense without the former even if not vice versa.
I don’t understand why this is an argument at all. No one stops the pumpking from saying “no, I won’t merge that branch because it does not make sense without that other branch which is not yet ready”. We have long had the notion that one bug/ticket can block another. Why is it so hard to conceive that one branch can also block another?
The branches to include in a release are not picked by dice throw or higher force. The pumpking makes a judgement call about which set of branches to merge at release time. This is nothing different from how it’s always been. The difference is merely that it’s not decided three years ahead of the release which features will be included in the next release. Instead, the set of features – I should say, the coherent set of features – is decided in the weeks/month before release.
Late binding for feature sets. Why that ostensibly has to imply an absence of judgement calls, I do not understand.
Aristotle: Thanks for the reply. I think you do have a good point!
On the other hand, maybe I chose a bad example. Features can be interdependent from a language and from an implementation point of view. In both cases, it may be that problems become apparent only after merging the branches. So while it may be worth a shot, such an approach isn't a silver bullet.
Oh no, it’s certainly not a silver bullet, and looking for one of those is harmful: it distracts from the long, slow, incremental slog which is the process by which things actually improve in the real world. There’s no single thing that will magically make everything better, nor does any process produce good results if it’s not driven by engaged people. I’m certainly under no illusions that switching to a feature branch model is the only thing that would have to change. But I do believe that it would be a significant – if still incremental – improvement, and that it would provide a sound basis for further improvements.
How do you explain successful time based releases in other open source projects? Fedora? Ubuntu? Linux Kernel? To me it's not important the releases happen to-the-day of the planned schedule (that rarely even happens in corporate software projects) just that it's a semi-accurate schedule that others can plan around. Slips happen and sometimes things derail the plan, but at least there's a planned schedule.
I love that I know a new Fedora release will happen about every 6 months. I can plan for that and roughly schedule when to upgrade my laptop. I wish I could say the same for Perl 5.10.01 and my business environment.
Michael, Fedora, Ubuntu and the Linux kernel have a lot of paid, full-time developers. I know the process quite well, since I was myself paid for years to work on the Mandriva Linux distribution. You can't compare commercial work and purely volunteer-based work as Perl 5. I agree that "open source" in the title is a simplification.
Post a Comment