Re^3: what happened to regular releases

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

Comment on Re^3: what happened to regular releases

Replies are listed 'Best First'.
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]