Front page | perl.perl5.porters |
Postings from June 2009
Re: Perl 5.10.1
From: David E. Wheeler
June 24, 2009 09:23
Re: Perl 5.10.1
Message ID: 64407F03-1531-4329-8BE8-4090AB1E28EE@kineticode.com
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
> 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.