On 6/4/02 1:11 PM, David Wheeler wrote: > On 6/4/02 9:59 AM, "John Siracusa" <[EMAIL PROTECTED]> claimed: >> 1b. 6PAN modules comply with an informal contract to maintain >> backward-compatibility within all N.MM versions, where N is constant. In >> other words, incompatible API changes are only allowed by incrementing the >> "major version" (e.g. going from 1.xx to 2.xx), and upgrades from one minor >> version to the next (e.g. 1.05 to 1.11) MUST be "safe" (i.e. >> "backward-compatible"). > > This might be asking too much -- it's not very perlish, in the sense of > TIMTOWTDI. It might make sense for DKs, but different people may want to use > the conventions their comfortable with. Perl is there for you to create > applications (and APIs) the way you want, not the way the gods demand.
Well, there are already "suggested" conventions for version number formats. Anyway, CPAN is supposed to be organized! It's not a free-for-all dumping ground for modules. Let the version numbering and API anarchists use SourceForge, I say! :) It's not like we're demanding EJB-like API rigidity. So we'll continue to have $foo.setBlah() and $foo.blah() and $foo.Set_Bar() in 6PAN, for better or for worse. All I'm asking for is some small meaning behind version numbering. Is that so wrong? :) >> Thoughts? Or has this stuff already been hashed out elsewhere and I missed >> it? :) > > One thing I think is as important -- or perhaps more important -- is to > enforce the presence of unit tests. There are a lot of modules on the CPAN > that have no tests, and most of them suffer for it. Heh, I was going to suggest that new minor-version 6PAN submissions automatically have all the earlier minor-version test suites run against them before allowing them to go into the archive... :) -John
