Re: what happened to regular releases

[Zaxo]

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

Sometimes a bug is discovered which demands a quick fix and immediate release. Sometimes development hits a lull from a design debate, or holidays, or demands of the money job.

There's no need to release a minimal revision just because you used to think it would be time for a release. That pressure is reserved for pay-to-play software with a marketing cycle.

[Perl Mouse]

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.

[tirwhan]

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.

[Perl Mouse]

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.