Front page | perl.perl5.porters |
Postings from July 2011
On Wed, Jul 20, 2011 at 5:41 AM, Nicholas Clark <nick@ccl4.org> wrote: > The counter to that is that a module *only* shipped in the core (and not > as dual-life on CPAN) doesn't let anyone upgrade it unless they upgrade > their entire installation. And it's not free (by any means) to *ship and > maintain* dual life modules from the core. Recent example being constant.pm, > where the logical thing in blead is to remove the code that copes with > older versions. Except that the module on CPAN wants to support those older > versions. When I was working on 5.15.0 I found several blead-upstream modules (in dist/*) that were ahead of CPAN. I wonder if we should be trying to sync those: (a) with every or every fewblead release (lots of work) (b) upon blead's "user-visible freeze" (concentrated work) (c) after stable release (concentrated work) I have mixed feelings. I slightly prefer (a) because it gets things into the wild faster for real user testing. Between (b) and (c) I prefer (b) for the same reason. There are some implications to these choices for how we manage dist/*, e.g. in version numbering as there is no point releasing a dev release to CPAN as it won't get indexed. It also raises the question of who should do the releasing -- the designated maintainer (herding cats) or the release manager (makes the job bigger.) What do people think? -- DavidThread Next