Good Programmers (like all of us here, right? ;-) know this rule of thumb: You don't tie a feature to a product version number during development! Too many places where I've worked, where the project lead wasn't really a Good Programmer, they used a branching scheme which declared that we shall branch for each release at the beginning of development for that release. That's fine when a "release" is one or two sprints long; but longer than that, and you inevitably run into this same situation: Feature X was supposed to go into Release V, but now we have to slip it to Release W... and now our branch is all whacked up.

For @larry to think that "main-line perl development can't possibly go so far as to need a new major version number before this new successor language is ready for release" reminds me an awful lot of the folly of "No one will ever need more than 640k" and such like as.

I find this obsession with version numbers—which good programmers know are nearly arbitrary—incredibly strange. I think of the years I refused to let them upgrade my box to Vista at work. How today I'd rather be on Server 2000 than X, I mean 10, of course.

Larry has paid–rather indirectly and with lots of help, but still–my immodest salary for years now. That this thread is devolving into offshoots "Fuck Larry for screwing Perl5," really, really sucks.

Reputation: 1 (+9 -8)

So sad...deliberately...rip it apart. His stubborn insistence ..Perl in all its forms is done for. Condemned, by the deliberate and malicious-aforethought, to a slow, inexorable decline Perhaps the saddest thing in life is living to witness the genius of youth become the twisted bitterness of old age.

That this ^^^^ hateful, ignorant, anonymous, pusillanimous wagging has a positive reputation is more of an embarrassment to Perl than a 50 year late "version" bump ever could be.

Indeed, this is no longer about version numbers. The feature and focus creep have made P6 an entirely different beast. It's a namespace problem now, good luck resolving that!

In the world of Muggles, it is quite normal to give your kids different names, such as 'Maria' and 'My'. Would you name your three daughters 'Mary'? And that someone has put the bread on your table, does not invalidate someone else's assessment. Non-sequitur. Argumentum ad passiones.

Timendi causa est nescire. Veritatem dies aperit. Quidquid latine dictum sit, altum sonatur.

While I don't, the project managers do tie features to specific versions - based on customer requirements. And, at least in the industry I work in, the major version numbers are tied to the project phases. Ideally, we have exactly 5 releases: 1.0.0 (simulation release) through 5.0.0 (production release). More often, we make minor releases as the customer requirements are "refined", and fix releases resulting from "contact with the real world"

FYI, when a customer of ours plans a new product - or new version of a product - they set the schedule. Then they write version 1.0.0 of their requirements and issue a "Request for Quote" (RFQ) to potential suppliers, including the schedule and version 1.0.0 requirements. Then, our project managers review the requirements, get estimates from product development (my division) and make a bid recommendation to higher level management, who decide whether to bid and the actual pricing. If the customer accepts our bid, the various product development managers are directed to assign teams to design and implement a control module based on the "core subset" of the version 1.x requirements for delivery by the Phase 1 due date. (I say 1.x because the customer inevitably continues to "refine" their requirements after the RFQ package is sent out.) Once my team (software) releases 1.0.0 to validation, we start on Phase 2 software.