Re^2: what happened to regular releases

Regular releases on a schedule are probably not a realistic goal for an open source project. Possibly not even desirable.

I think regular releases are very desirable. Even for an open source project. Just look at how 5.8.1 came to be. The first release candidate for 5.8.1 came a year after the release of 5.8.0. It took 5 release candidates, and two and a half months of hard work to get 5.8.1 out. Why? Because a year after the previous release, and no scedule for a next release, and 5.10 man years away, everyone wanted their new feature/bug-fix in.

If you have a garanteed release cycle, one every three or four months, it's easy to say to someone "you missed the deadline for this release' code-freeze, in three months time there's another". But what do you say if there's no scedule? "That's a great fix, we'll use it some time in the future"?

That pressure is reserved for pay-to-play software with a marketing cycle.

Perl isn't free. That is, it isn't free because making/maintaining/extending it doesn't cost resources. Maintaining Perl means people have to spend resources - not so much money, as well putting in time and lending expertise (and it takes investment to build expertise). The ratio of people contributing to Perl vs the people using Perl is very low. Which means that marketing is important for Perl. For every people contributing to Perl, you need thousands of people using Perl. If having regular releases is good from a marketing perspective - it will benefit Perl itself.

Perl --((8:>*

Comment on Re^2: what happened to regular releases

Replies are listed 'Best First'.
Re^3: what happened to regular releases by tirwhan (Abbot) on Nov 28, 2005 at 11:25 UTC
I think you're conflating regular releases with frequent releases here. The latter are usually desirable (and give all the benefits you name in your post), while the former introduce some nasty side-effects and IMO are not a worthwhile goal. Smacks too much of five-year-plan mentality to me. I agree it's good to formulate a release plan and stick to it as much as possible, but a forced recurring release date just leads to unfixed bugs and inefficient organisation. Commercial companies have to do it because for some reason they are viewed as more professional if they can ship a piece of crap on time rather than a functioning app some time later. But free software doesn't have to care about that and shouldn't want to. Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -- Brian W. Kernighan	[reply]
Re^4: what happened to regular releases by Perl Mouse (Chaplain) on Nov 28, 2005 at 12:38 UTC
Eh, leads to "unfixed bugs"? A bug can only be fixed if there's a release - no release implies no bug fix (a bug isn't fixed if the fix only lives in a source repository). If you release four times a year, there are four releases a year that can fix your bug. You know when the deadlines for the code freeze are, and anyone can anticipate on the code freeze by sending in their patches early. With releases on unknown times, even if "frequent", there will always be this new patch to be added, fixing one bug, opening another. And another. And another. Just witness Perl development for the past 5 years. I'd say, the best thing that happened to Perl in the past five years was Nicolas decision to do frequent, regular releases. Too bad it's already slipping. `Perl --((8:>*`	[reply]
Re^5: what happened to regular releases by tirwhan (Abbot) on Nov 28, 2005 at 13:12 UTC
Unfixed bugs because the release needs to be pushed out of the door before a bug fix is in and tested, just because it is time to release. As opposed to delaying the release by however long it takes in order to incorporate an important bug fix and not release a buggy version. Instead of fixing four release dates a year, take things one step at a time. Once a release is out of the door, fix a future feature freeze day. After that has passed, fix a release date. Any feature patches that arrive after the freeze date go into the next release, unless they're really important, in which case the release gets pushed back by however long it takes to incorporate. The release happens whenever the code is sufficiently bug-free to satisfy the project manager(s). Yes, you need to draw the line somewhere and say this patch goes in and that one doesn't, but that's just a management issue. It means you make the cut based on a technical evaluation, which is surely superior to making the decision based on the time that has passed since a certain Middle-Eastern man was (or was not, whichever your persuasion may be) born. Besides, "sending in their patches early" doesn't really happen very much, does it? Most patches are submitted just before the code freeze date. As a project manager you need to deal with that issue. I personally really like the new Linux kernel method of having extremely short windows between a project release and a feature freeze (currently two weeks), but there are bound to be different time scales which are ideal for different projects. Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -- Brian W. Kernighan	[reply]