Front page | perl.perl5.porters |
Postings from October 2003
Re: 5.8.2 is built as 5.8.1
From: Andy Dougherty
October 17, 2003 06:41
Re: 5.8.2 is built as 5.8.1
Message ID: Pine.SOL.firstname.lastname@example.org
On Thu, 16 Oct 2003, Jim Cromie wrote:
> Yitzchak Scott-Thoennes wrote:
> >That's no fix. When 5.9.0 is released, I want to be able to install
> >it. As soon as a few more changes are applied, I want to be able to
> >install that as 5.9.1-tobe.
If you want to install non-released versions or developer versions, then
you need to take special care that they don't interfere with the released
versions. Or, if you *do* want to study their interaction with
previously-released versions, then you must take special care to see that
they are installed in a way to study whatever it is you want to study.
I know of no solution that will work for everyone, because different
schemes would break different things for different people.
Here's just one example: the shared libperl.
Suppose you have installed 5.8.1, and its shared libperl.so is in
$prefix/lib/5.8.1/$archname/CORE/libperl.so. Now, suppose you are
installing a post-5.8.1 snapshot. If that snapshot calls itself 5.8.1,
then you might inadvertantly end up using the existing 5.8.1 libperl.so,
not the one you just built.
Simple, you say -- call the new snapshot 5.8.2 instead. Then you build
and install it so the experimental post-5.8.1 snapshot shared libperl is
in $prefix/lib/5.8.2/$archname/CORE/libperl.so. No conflicts, so far.
But -- now suppose the *real* 5.8.2 comes out, and is significantly
different in some way from your already-installed snapshot (e.g. hashes
are changed in a binary incompatible way). Now, as you try to build the
real 5.8.2, you're picking up your experimental incompatible post-5.8.1
snapshot libperl.so instead!
What to do? I normally recommend using a different $prefix for installing
> why not use a suffix, such as -alpha or -blead, as is done with -RC1, etc.
> the right suffix would convey the status unambiguously,
> and doesnt require incessant @patchnum bumps either.
> A related/follow-on question would be whether @INC should contain the
I think not. That would defeat the automatic searching of previous
Maintenance track: I would recommend bumping the patchlevel when the
pumpkin holder believes it is time to release snapshots for testing with
the world outside perl (e.g. other programs or modules that may have
patchlevel-specific code). Don't bump it too soon, because then it gets
out into the world and you may get bogus bug reports for some time to
come. But don't wait too long either, because there is likely some code
out there that has patchlevel-specific workarounds in it. Also, the perl
core itself has a few patchlevel-specific parts that need to be tested.
(Bonus trivia question: Who remembers what the first 5.000 release called
Development track: I would recommend releasing an experimental 5.9.0 as
soon as Hugo is comfortable doing so (considering both the quality of the
code and broader factors such as the release plans for the 5.8.x track.)
Once the 5.odd series is started, developers will need to explicity use
-Dusedevel, at which point, they presumably know what they are doing.
Obviously, no one should expect stability in a development track, so
reasonably frequent 5.9.x releases would probably be a good idea and would
somewhat minimize these issues. (Every 5.9.x release doesn't have to be
announced -- big-time announcements can be made after-the-fact if it looks
like a particular 5.9.x. release is worth announcing. If it isn't, then
don't. But still bump the patchlevel with significant changes.)
For dedicated developers: You have the code. You know what you're doing.
Edit patchlevel.h as you see fit to test whatever it is you want to test.
Andy Dougherty email@example.com