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

Re: Perl 5.10.1

Thread Previous | Thread Next
David E. Wheeler
June 24, 2009 09:23
Re: Perl 5.10.1
Message ID:
On Jun 24, 2009, at 2:48 AM, David Golden wrote:

> It may.  But that's part of a broader debate about speed of evolution
> versus stability.

I don't see how speed of evolution and stability are in conflict here.  
Where is the contention between them?

> I'm talking about something much narrower.  Rafael suggested a library
> of "important" patches for those who need them.  I'm taking that one
> step further and saying it doesn't have to be patches -- it can be
> full-fledged, ready to compile source trees.

Yeah, it can be a tag in Git. Which GitHub, for example, would turn  
into a tarball. Which is, you know, kind of like a release.

> Moreover, it can happen entirely to the side of p5p.  This is a good
> thing for those who want a fix that isn't blessed/sanctioned.
> My example of getting ancient perls to build on my system is an
> example.  If I want to be able to test my distros against every major
> perl release, I don't want to have to patch every single one of them
> to get it to build.  p5p didn't like my idea of adding "maint-5.X.Y"
> branches to backport build-fixes for "perl-5.X.Y" branches.  I forget
> why -- probably something about not implying that anyone is supporting
> those older releases or something.  Ok, fine.  I don't really care to
> waste my time on that argument and I don't need to because I don't
> need it to be in the official repo -- it's in mine.

You mean like maintenance branches for 5.8.7, 5.8.8, 5.8.9, 5.10.0,  
5.10.1, etc? That's crazy talk! So I probably misunderstand.

> So I've done the work already.  How can the next person who wants to
> build 5.6.2 for whatever reason benefit?  Get pointed to my repo, pull
> the right branch and build.  Easier than trolling through a directory
> of patches, finding the right one, applying it, etc.  And if someone
> thinks they can do a better 5.6.2 than I can, they can easily publish
> their own branch.

Well this is also a symptom of a lack of a proper deprecation and  
support policy.

> Git democratizes Perl.

Oh, no question.

> In my book, that's a good thing.  Even for p5p, it may be good in that
> minor issues off the main line of development can be fixed and
> available by others.

Sure, with patches going upstream. This is a great approach to solve  
your particular itch, and probably isn't appropriate for core. But its  
use is orthogonal to core's frequent, regular release of stable  
supported releases of Perl, IMHO.



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