The date matches MM/01/YYYY -- it's a release!
Calling whatever happens to be lying around on a particular date a "stable release" is a laughably bad idea (the "rhythm method" is also lousy birth control). A "release" is something you want lots of people to use; "the stuff in version control on the first of the month" is something else entirely.
Perl releases used to take awhile -- so do releases of POSIX, HTML, C, and C++ -- and that was not a bad thing. It's the difference between a platform and a fad.
I blog about Perl.
If that plus infantile puns is all you got out of three explanations in small words then please don’t waste your time trying to comprehend what is beyond you.
Perl releases of even version numbers always consist of a number of changes that have been vetted and found for good by multiple people. These are what will go into 5.16.
Now a person comes along with a possible vulnerability, the details of which are not made clear and implies that to fix it in user code without core changes would require some tribal knowledge to be added. As a response the question is raised whether all fixes up until then should be delayed indefinitely until a fix for this nebulous vulnerability is created. This seems silly to me.
People on previous Perls will need to contend with the lack of the vetted fixes and the lack of a fix for the vuln either way. Depriving them of vetted the fixes does nobody any good and keeping up the release rythm means that the fix for the vuln will come about whenever it is defined, created and tested.
Perfect is the enemy of good.
I for one would rather have perl release "too often" than not enough.
Merely to look upon Your words in utter incomprehension is an honor of which I am wholly unworthy.
Until software releases are made by robots, or we eradicate featuritis, date-based release does maintain some advantages over feature-based release.
False dilemma. It's possible to have time based releases that follow a careful and well thought out release process. That's exactly what Perl does. It's not just whatever happens to be checked in at the time.
It's a shame you actually used Aristotle's post to make your point, since he expressed it there in a concise and beautiful manner:
The *date* is irrelevant.
The *rhythm* is paramount.
It's a shame you did not get that point.
Lucky for you (and me, and others), Leon Timmermans does well to stresses this point in in a reply here:
I for one would rather have perl release "too often" than not enough.
These are not difficult concepts (which are *always* open for discussion within the community) and I have yet to understand why they warrant such disrespectful and mocking behavior towards people who've done so much for the language and the community.
Sawyer: I actually do not like putting it as "rather too often than not enough". That implies that the choice is between stagnation and recklessness and that we'd then rather have the latter (when nothing could be further from the truth), so it isn't a lot better than what the foo wrote.
The key point, which he has chosen to miss, is that by the time the ship date rolls around, blead has not had new features merged or committed in almost three months – only fixes. And if a feature wasn’t already working well enough anyway before the freeze, too bad, it didn’t get merged; it has to sit on a branch and wait for next round. So “whatever happens to be lying around on a particular date” is of release quality if that particular date happens to be the release date.
It is precisely “something you want lots of people to use” – all the features from the last development period that you want end users to have. Any feature that’s done, the users get: it does not get stuck in blead for years like with feature-based releases.
The difference to feature-based releases, the only difference, is that instead of waiting until you can ship features X, Y, and Z (in the meantime also picking up features M, N, I, J and K), you instead just ship the ones that are done and hold back the ones that aren’t. The question gets turned on its head: instead of “can we ship all the features yet?” it becomes “which features can we ship this time?”. But otherwise, you do the exact same things as before.
Somehow when people read “time-boxed release” they hear “who needs release engineering” no matter how you try to explain that it means more (because more regular) release engineering.