develooper Front page | perl.perl5.porters | Postings from July 2011

Managing upstream blead modules (was Re: Perl with batteries included?)

Thread Next
David Golden
July 20, 2011 03:10
Managing upstream blead modules (was Re: Perl with batteries included?)
Message ID:
On Wed, Jul 20, 2011 at 5:41 AM, Nicholas Clark <> 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,
> 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?

-- David

Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About