Re: Perl 5.10.1

Front page | perl.perl5.porters | Postings from June 2009

Thread Previous | Thread Next

From:

Marvin Humphrey

Date:

June 30, 2009 10:58

Subject:

Re: Perl 5.10.1

Message ID:

20090630175749.GA24615@rectangular.com

On Tue, Jun 30, 2009 at 09:15:54AM -0700, David E. Wheeler wrote:

> >This is a huge problem for me and other CPAN authors with large,  ambitious
> >distros.  I just released KinoSearch 0.30_01 a couple weeks ago.  In  a
> >world with sane versioning, it would have been KinoSearch 4.00_01, to be
> >followed shortly by 4.00 -- because this is really the fourth generation
> >for  that code base.
> 
> Why isn't it 3.99_99, soon to be 4.00? How you version a module like  
> that is entirely up to you.

The point is that "4.00", or "1.00", or any stable release is not imminent.
It's going to stay an alpha for a while longer.

That way, we won't disrupt users for whom 0.165 is adequate until the last
moment.  But 0.165 contains mostly three-year-old code, has broken UTF-8
support, doesn't support sorting by field values or range queries, is several
times slower for indexing, doesn't exploit mmap to minimize search-time
process memory footprint and make launching Searchers cheap and instantaneous,
exposes far fewer public classes and pluggability/subclassing hooks, etc.

> >But because we can't have maint branches yet rapid innovation is
> >ongoing, it's still in alpha.  It's been a lot less useful to the Perl
> >community than it might have been.
> 
> I think I missed something here, I don't follow.

If Perl/CPAN supported maint branches for modules, then we would have had four
stable branches.

  1.x - The original, pure-Perl Search::Kinosearch.
  2.x - KinoSearch 0.05-0.165
  3.x - KinoSearch 0.20_xx
  4.x - KinoSearch 0.30_xx

Not only would innovations have been made available sooner, but users could
have counted on stability of API and file format within their maint branch,
upgrading at their leisure.  Judging by the known userbase and the fact that
independently authored KSx CPAN distros exist at all, I think it's fair to say
that KinoSearch has been useful to the Perl community -- but I don't think
it's outrageous to assert that it would have been *more* useful stripped of
its big fat alpha WARNING.

In retrospect, perhaps it would have made sense to fork into new namespaces
continually -- KinoSearch1, KinoSearch2, and so on.  And there are some
accidents of history (Apache Lucy politics, new employers with new feature
requests) that have artificially drawn out the alpha period somewhat for
unrelated reasons.  

But if Perl/CPAN offered support for module maintenance branches, none of that
would have mattered.

I'd start by making the first module search directory correspond to the major
version of the distro:  

  Foo::Bar version 1.x => $base/1/Foo/Bar.pm
  Foo::Bar version 2.x => $base/2/Foo/Bar.pm

It would take a lot more than that to get things to work -- major version
information would have to be part of the namespacing in the stash hierarchy so
that multiple module versions could be loaded simultanously -- but that would
be my step 1 if starting from scratch.

Returning to Nick's original message...

   [Which is just as much a problem for modules only on CPAN. And happens,
   given the grumbling I hear from nearby when certain CPAN modules change
   details of the behaviour published APIs]

If there were no good reason to break backwards compat within a major version
of a CPAN distro, then we could reserve our grumbles for truly irresponsible
authors and set free those who strive for a balance between stability and
innovation.

Marvin Humphrey

Thread Previous | Thread Next