« Help With My AnyEvent + Plack Tutorial | Main | The Essence of Compromise, or why Pumpkin Perl version 20 »

02/18/2013

TrackBack

TrackBack URL for this entry:
http://www.typepad.com/services/trackback/6a0128764b0ec7970c017c36f3f948970b

Listed below are links to weblogs that reference Pumpkin Perl, Version 20.:

Comments

Feed You can follow this conversation by subscribing to the comment feed for this post.

Xdg

I mentioned in passing in my post on the topic that 'Pumpkin v20' is a bad idea if the regular annual releases continue to be v22, v24, etc.

We don't want annual, generally backwards-compatible releases to be bumping major versions like that or when we do make a major change, there's no way to tell "minor" major versions from "major" major versions.

Thus, if this change is made, I favor "Pumpkin Perl 1, version 20" so there is room for a "Pumpkin Perl 2" later.

There are other version solutions that accomplish similar things, but mostly, I want to convince people that the idea of just using the annual release version as the major version is not a very good idea.

john

I sympathize with the feeling here, but I think the more simple we make this the better. Basically what we say is that Pumpkin Perl is the friendly name for Perl revision 5, so that in Makefile.PL if you want to declare a minimum Perl version requirement, you'd still say Perl 5.xxx.xxx otherwise I think we totally bust up and chance of backward compatibility. Saying Pumpkin Perl 1, version 20, I'm not sure what that looks like in a Makefile...

The history of rebranding indicates more simple == more chance of success. Lets not think about this like programmers.

The comments to this entry are closed.