5.8.4 RC1
Nicholas Clark
When the Night Mail's ready to depart,
Saying 'Skimble where is Skimble has he gone to hunt the thimble?
We must find him of the train can't start.'
All the guards and all the porters and the stationmaster's daughters
They are searching high and low,
Saying 'Skimble where is Skimble for unless he's very nimble
Then the Night Mail just can't go'
At 11.42 then the signal's overdue
And the passengers are frantic to a man--
Then Skimble will appear and he'll saunter to the rear:
He's been busy in the luggage van!
He gives one flash of his glass-green eyes
And the the signal goes 'All Clear!'
And we're off at last of the northern part
Of the Northern Hemisphere!
from 'Skimbleshanks: The Railway Cat' by T.S. Eliot
Get it now from
http://opensource.fotango.com/~nclark/perl-5.8.4-RC1.tar.bz2
(or s/bz2$/gz/ if you really want a 25% larger download.)
coming soon to a CPAN mirror near you soon as
ftp://ftp.cpan.org/pub/CPAN/authors/id/N/NW/NWCLARK/perl-5.8.4-RC1.tar.bz2
Once it's propagated round the CPAN mirrors I'll make an announcement
on use.perl
I'm interested in confirmation of binary compatibility between 5.8.4 and
modules compiled under previous 5.8.x releases, and anything which is a new
bug in 5.8.4, particularly if it breaks current modules on CPAN.
rsync ftp.linux.activestate.com::perl-5.8.x/
will be at RC1 for the next day or so.
All being well the real thing arrives in about a week.
Nicholas Clark
Randal L. Schwartz
Randal> These need refreshing from the CPAN against RC1:
And all "make install" fine against RC1.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<mer...@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Dave Mitchell
> I'm interested in confirmation of binary compatibility between 5.8.4 and
> modules compiled under previous 5.8.x releases, and anything which is a new
> bug in 5.8.4, particularly if it breaks current modules on CPAN.
Runs fine with my day job code and a bunch of modules built under 5.8.1
--
That he said that that that that is is is debatable, is debatable.
Randal L. Schwartz
These need refreshing from the CPAN against RC1:
cpan> r
CPAN: Storable loaded ok
Going to read /opt/perl/cpan/Metadata
Database was generated on Mon, 05 Apr 2004 20:50:39 GMT
Package namespace installed latest in CPAN file
Digest 1.05 1.06 G/GA/GAAS/Digest-1.06.tar.gz
ExtUtils::Command 1.05 1.07 M/MS/MSCHWERN/ExtUtils-MakeMaker-6.21.tar.gz
Filter::Simple 0.78 0.79 D/DC/DCONWAY/Filter-Simple-0.79.tar.gz
I18N::LangTags 0.29 0.30 S/SB/SBURKE/I18N-LangTags-0.30.tar.gz
Locale::Maketext 1.08 1.09 S/SB/SBURKE/Locale-Maketext-1.09.tar.gz
Net::Cmd 2.24 2.25 G/GB/GBARR/libnet-1.18.tar.gz
Pod::LaTeX 0.55 0.56 T/TJ/TJENNESS/Pod-LaTeX-0.57.tar.gz
Text::Soundex 1.01 3.02 M/MA/MARKM/Text-Soundex-3.02.tar.gz
if 0.03 0.0401 I/IL/ILYAZ/modules/if-0.0401.tar.gz
Andy Lester
Perhaps this should wait until he gets 6.22 out? He's got a 6.21_03 out
right now.
xoa
--
Andy Lester => an...@petdance.com => www.petdance.com => AIM:petdance
Greg Matheson
> I'm interested in confirmation of binary compatibility between 5.8.4 and
> modules compiled under previous 5.8.x releases, and anything which is a new
> bug in 5.8.4, particularly if it breaks current modules on CPAN.
>
> rsync ftp.linux.activestate.com::perl-5.8.x/
>
> will be at RC1 for the next day or so.
Although perl-5.8.x built yesterday I swear,
perl-5.8.4-RC1 doesn't build today.
On Win98, with MinGW-3.1.0.
It hung after building miniperl and as it started making Encode
Running Makefile.PL in Encode
C:\CYGWIN\HOME\GREG\PERL-5~1.4-R\MINIPERL.EXE -IC:\cygwin\home\greg\perl-5.8.4-RC1\win32\..\lib Makefile.PL INSTALLDIRS=perl PERL_CORE=1
Checking if your kit is complete...
Looks good
Writing Makefile for Encode::Byte
Writing Makefile for Encode::CN
Writing Makefile for Encode::EBCDIC
Writing Makefile for Encode::JP
Writing Makefile for Encode::KR
Writing Makefile for Encode::Symbol
Writing Makefile for Encode::TW
Writing Makefile for Encode::Unicode
Writing Makefile for Encode
Making Encode
C:\M\BIN\DMAKE.EXE -S
[perl-5.8.x just hung now, when I tried building it, patch 22650.]
I believe this is the same problem of long command lines
with MakeMaker on Win98 that I mention here:
http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2004-02/msg00580.html
and
http://www.mail-archive.com/make...@perl.org/msg01364.html
These changes made it into ExtUtils-MakeMaker-6.21_3, but not
perl-5.8.4-RC1.
Perhaps the perldelta section:
> =head1 Installation and Configuration Improvements
> The build process on both VMS and Windows has had several minor improvements
> made. Perl should now build on Windows 95. C<perl.exe> on Windows now has a
> "Camel" logo icon. The use of a camel with Perl is a trademark of O'Reilly
> and Associates, and is used in the Perl core distribution with their
should say:
Perl should now build on Windows 95 with a few tweaks.
--
Greg Matheson, Taiwan
Stas Bekman
lib/ExtUtils/t/Constant..............Can't locate Term/ANSIColor.pm in @INC
(@INC contains:
/home/stas/perl/5.8.4-ithread/lib/5.8.4/i686-linux-thread-multi
/home/stas/perl/5.8.4-ithread/lib/5.8.4
/home/stas/perl/5.8.4-ithread/lib/site_perl/5.8.4/i686-linux-thread-multi
/home/stas/perl/5.8.4-ithread/lib/site_perl/5.8.4
/home/stas/perl/5.8.4-ithread/lib/site_perl .) at /usr//bin/cc line 91.
BEGIN failed--compilation aborted at /usr//bin/cc line 91.
make[3]: *** [ExtTest.o] Error 2
FAILED at test 3
lib/ExtUtils/t/Embed.................Can't locate Term/ANSIColor.pm in @INC
(@INC contains:
/home/stas/perl/5.8.4-ithread/lib/5.8.4/i686-linux-thread-multi
/home/stas/perl/5.8.4-ithread/lib/5.8.4
/home/stas/perl/5.8.4-ithread/lib/site_perl/5.8.4/i686-linux-thread-multi
/home/stas/perl/5.8.4-ithread/lib/site_perl/5.8.4
/home/stas/perl/5.8.4-ithread/lib/site_perl .) at /usr//bin/cc line 91.
BEGIN failed--compilation aborted at /usr//bin/cc line 91.
FAILED at test 1
Both due to /usb/bin/cc being the gcc colorgcc wrapper in perl (v1.3.2). Not
really a problem of 5.8.4, but I haven't seen this problem before.
Running tests standalone shows:
% perl lib/ExtUtils/t/Constant
...
# make = 'make'
ok 3
% perl lib/ExtUtils/t/Embed.t
1..9
# cc -o embed_test -I.. -D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS
-DDEBUGGING -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm
-I/home/stas/perl/5.8.4-ithread/lib/5.8.4/i686-linux-thread-multi/CORE
embed_test.c -L.. -lperl -Wl,-E
-Wl,-rpath,/home/stas/perl/5.8.4-ithread/lib/5.8.4/i686-linux-thread-multi/CORE
-L/usr/local/lib
/home/stas/perl/5.8.4-ithread/lib/5.8.4/i686-linux-thread-multi/auto/DynaLoader/DynaLoader.a
-L/home/stas/perl/5.8.4-ithread/lib/5.8.4/i686-linux-thread-multi/CORE -lperl
-lnsl -ldl -lm -lcrypt -lutil -lpthread -lc
ok 1
Both triggering the coloring action of colorgcc. colorgcc's shebang is:
#!/usr/bin/perl
which has Term::ANSIColor installed:
/usr/bin/perl -MTerm::ANSIColor -le 'print Term::ANSIColor->VERSION'
1.07
perl-5.8.4-RC1 doesn't have this module, but I'm not sure how colorgcc gets to
call the perl that's being tested at the moment...
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:st...@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Graham Barr
> Net::Cmd 2.24 2.25
> G/GB/GBARR/libnet-1.18.tar.gz
yes, I need to update the repository, which is currently at 1.17. I was
leaving it a while after release to wait for bug reports, then got
side-tracked :-)
Graham.
Andrew Dougherty
> I had an interesting glitch during 'make test':
>
> lib/ExtUtils/t/Constant..............Can't locate Term/ANSIColor.pm in @INC
> (@INC contains:
> /home/stas/perl/5.8.4-ithread/lib/site_perl .) at /usr//bin/cc line 91.
> Both due to /usb/bin/cc being the gcc colorgcc wrapper in perl (v1.3.2). Not
> really a problem of 5.8.4, but I haven't seen this problem before.
We've encountered this before. See the message threads
http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2003-05/msg00232.html
which ends with Jarkko's prophetic remark:
> Urk. How are you going to run the ExtUtils:: tests...?
and
http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2003-07/msg00831.html
> perl-5.8.4-RC1 doesn't have this module, but I'm not sure how colorgcc gets to
> call the perl that's being tested at the moment...
I forget all the details, but it's related to -Duseshrplib, and possibly
to the use of LD_PRELOAD. Do you, by any chance, already have a
shared library for perl-5.8.4 with ithreads installed?
--
Andy Dougherty doug...@lafayette.edu
Stas Bekman
> On Mon, 5 Apr 2004, Stas Bekman wrote:
>
>
>>I had an interesting glitch during 'make test':
>>
>>lib/ExtUtils/t/Constant..............Can't locate Term/ANSIColor.pm in @INC
>>(@INC contains:
>>/home/stas/perl/5.8.4-ithread/lib/site_perl .) at /usr//bin/cc line 91.
>
>
>>Both due to /usb/bin/cc being the gcc colorgcc wrapper in perl (v1.3.2). Not
>>really a problem of 5.8.4, but I haven't seen this problem before.
>
>
> We've encountered this before. See the message threads
> http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2003-05/msg00232.html
>
> which ends with Jarkko's prophetic remark:
>
>>Urk. How are you going to run the ExtUtils:: tests...?
>
>
> and
> http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2003-07/msg00831.html
Thanks Andrew, that's pretty fresh. It doesn't bother *me* but others may
report this as a problem.
>>perl-5.8.4-RC1 doesn't have this module, but I'm not sure how colorgcc gets to
>>call the perl that's being tested at the moment...
>
>
> I forget all the details, but it's related to -Duseshrplib, and possibly
> to the use of LD_PRELOAD. Do you, by any chance, already have a
> shared library for perl-5.8.4 with ithreads installed?
Not exactly. I had 5.8.4-tobe (pre-RC1) installed, which confusingly lived in
the 5.8.3 tree. 5.8.4-RC1 finally had its dir coined 5.8.4. And I had to
rebuild everything twice :(
Andy Dougherty
> On Mon, 5 Apr 2004, Stas Bekman wrote:
> > lib/ExtUtils/t/Constant..............Can't locate Term/ANSIColor.pm in @INC
> > (@INC contains:
> > /home/stas/perl/5.8.4-ithread/lib/5.8.4/i686-linux-thread-multi
> > /home/stas/perl/5.8.4-ithread/lib/5.8.4
> > /home/stas/perl/5.8.4-ithread/lib/site_perl/5.8.4/i686-linux-thread-multi
> > /home/stas/perl/5.8.4-ithread/lib/site_perl/5.8.4
> > /home/stas/perl/5.8.4-ithread/lib/site_perl .) at /usr//bin/cc line 91.
[where /usr/bin/cc is the 'colorgcc' perl script.]
> > perl-5.8.4-RC1 doesn't have this module
> We've encountered this before. See the message threads
> http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2003-05/msg00232.html
> and
> http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2003-07/msg00831.html
Wait. I was too hasty. perl-5.8.4-RC1 *does* have that module. The
problem is that the @INC used in the Constant.t test is wrong.
Looking carefully at the second line:
> > /home/stas/perl/5.8.4-ithread/lib/5.8.4
that's $src/lib/5.8.4, where $src is where you have the perl sources.
But the perl sources don't have the library files down in a 5.8.4
subdirectory. That line should be a plain
> > /home/stas/perl/5.8.4-ithread/lib
when the test is run as part of the core perl distribution.
If it's running as part of a stand-alone CPAN module, then perhaps the
@INC logic is correct, but in this case it's not.
The problem is that I'm not sure offhand where that @INC's getting set --
I still think it might have to do with the way the main makefile is
calling things to ensure that miniperl runs with the just-build shared
library, but there might also be something more going on.
--
Andy Dougherty doug...@lafayette.edu
sch...@pobox.com
> > ExtUtils::Command 1.05 1.07 M/MS/MSCHWERN/ExtUtils-MakeMaker-6.21.tar.gz
>
> Perhaps this should wait until he gets 6.22 out? He's got a 6.21_03 out
> right now.
I'm waiting to hear back from the VMS folks before putting out 6.22.
--
Michael G Schwern <sch...@pobox.com> http://www.pobox.com/~schwern/
Perl Quality Assurance <per...@perl.org> Kwalitee Is Job One
Nicholas Clark
> >>>>> "Randal" == Randal L Schwartz <mer...@stonehenge.com> writes:
>
> Randal> These need refreshing from the CPAN against RC1:
If they weren't in blead by the code freeze deadline they didn't get in.
And to keep my "job" within the bounds of what I can do without burning out,
I need to leave it to the blead pumpking and all his deputies to keep blead
in snyc. (both with CPAN and patches)
> And all "make install" fine against RC1.
Thanks. Positive feedback is useful.
Nicholas Clark
Randal L. Schwartz
Nicholas> If they weren't in blead by the code freeze deadline they didn't get in.
But RC1 isn't a code freeze. Had I known you were getting close to
RC1, I would have sent this message a few days earlier.
These *should* go in for RC2.
Stas
> On Tue, 6 Apr 2004, Andrew Dougherty wrote:
>
>
>>On Mon, 5 Apr 2004, Stas Bekman wrote:
>
>
>>>lib/ExtUtils/t/Constant..............Can't locate Term/ANSIColor.pm in @INC
>>>(@INC contains:
>>>/home/stas/perl/5.8.4-ithread/lib/5.8.4/i686-linux-thread-multi
>>>/home/stas/perl/5.8.4-ithread/lib/5.8.4
>>>/home/stas/perl/5.8.4-ithread/lib/site_perl/5.8.4/i686-linux-thread-multi
>>>/home/stas/perl/5.8.4-ithread/lib/site_perl/5.8.4
>>>/home/stas/perl/5.8.4-ithread/lib/site_perl .) at /usr//bin/cc line 91.
>
>
> [where /usr/bin/cc is the 'colorgcc' perl script.]
>
>
>>>perl-5.8.4-RC1 doesn't have this module
>
>
>>We've encountered this before. See the message threads
>>http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2003-05/msg00232.html
>>and
>>http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2003-07/msg00831.html
>
>
> Wait. I was too hasty. perl-5.8.4-RC1 *does* have that module. The
> problem is that the @INC used in the Constant.t test is wrong.
> Looking carefully at the second line:
>
> > > /home/stas/perl/5.8.4-ithread/lib/5.8.4
>
> that's $src/lib/5.8.4, where $src is where you have the perl sources.
> But the perl sources don't have the library files down in a 5.8.4
> subdirectory.
Well, no, that's the path of the to-be installed perl (I built with
--prefix=/home/stas/perl/5.8.4-ithread, the source was
/home/stas/perl.org/perl-5.8.4/)
> That line should be a plain
>
> > > /home/stas/perl/5.8.4-ithread/lib
/home/stas/perl.org/perl-5.8.4/lib
in my case really :)
> when the test is run as part of the core perl distribution.
> If it's running as part of a stand-alone CPAN module, then perhaps the
> @INC logic is correct, but in this case it's not.
>
> The problem is that I'm not sure offhand where that @INC's getting set --
> I still think it might have to do with the way the main makefile is
> calling things to ensure that miniperl runs with the just-build shared
> library, but there might also be something more going on.
But yes, the to-be-installed @INC is definitely useless during 'make test'.
Nicholas Clark
> >>>>> "Nicholas" == Nicholas Clark <ni...@ccl4.org> writes:
>
> Nicholas> If they weren't in blead by the code freeze deadline they didn't get in.
>
> But RC1 isn't a code freeze. Had I known you were getting close to
> RC1, I would have sent this message a few days earlier.
The specific code freeze date was first announced 6 months ago.
The most recent mention of it was in the perl5-porters summary last week:
http://use.perl.org/article.pl?sid=04/03/30/100238&mode=nested&tid=12
> These *should* go in for RC2.
There may not be an RC2.
In my view there is no mandate that *anything* should go into a release.
And specifically I am favouring stability over uptodateness. I'm the one
who gets egg on his face if a release is duff, and I'm being careful.
"Code freeze" actually is getting implemented as "no new code" after the
release candidate. Between that and release, things only roll back
The need for another release candidate implies that the first candidate
wasn't up to the job, so if there is cause for another RC (which only delays
the final release and hence cuts the time between it and the next code freeze)
minor, stable things can go in. In turn, the policy of time based releases
is specifically designed to prevent the mad rush of patching that used to
happen just before a stable release - a mad rush of patching being the least
conducive thing to code stability.
The policy of nothing new more a save-my-face option - the intent is that
release will contain code that is either
a: what was in the last release candidate
b: what in the previous stable release
The intent is that if anyone reports a core bug tickled by a CPAN module
in the new release itself, then the bug will also be visible either in the
release candidate, or it will turn out that the bug was present in the
previous stable version. Either way, I had not prevented the bug from being
reported prior to the stable release, and an opportunity had existed to
report that the release candidate was buggy. (This fails if the bug is
caused by the interaction of changed and unchanged code)
If the author of a CPAN module makes a release just before "code freeze"
(whenever that might be relative to RCs or perl releases) and 3 days later
someone finds a major but subtle bug in it, then the author can release a
new version PDQ. This minimised that damage.
However, if I roll that module in and make a perl release WITHIN those 3 days,
then perl has that duff module. And I can't make a new perl release within
3 days, and I'm not sure if I want to make a whole new release if it
transpires that one module in lib/ is embarrassing. And most people don't
keep systems up-to-date, so many people aren't going to download the newer
fixed versions from CPAN. Anecdotal evidence about ISPs reluctance to
install anything from CPAN, even useful stuff not in the core, suggests that
many perl installations are the core tarball only. Hence I'm mindful of the
need to keep core releases good and clean. The price for that is that they
might be slightly out of date. In other words, they're not bleeding edge.
But for a goal of stability, this feels like the right thing.
I want people to be able to drop the entire new release in place, and find
that all their acceptance tests pass first time. And I want this for 5.8.4,
5.8.5, 5.8.6, 5.8.7 etc. Which means that I need to be careful. The
probability of me not screwing up any of those releases is exponential
with the number of releases. The probability of screwing up any release
is exponential with the complexity. (I have to independently not screw up
each part in order to not screw the whole up). If there's a 5% chance of
any change being a problem, then I only have to make 14 changes before it's
51% likely that I have at least 1 problem.
I realise that it looks somewhat silly if perl ships with modules that are
slightly out of date. But it looks stupid if perl ships with modules that
are broken, and it's highly visible if a new "stable" release comes alone
shortly after to fix them, advertising the very cock up we'd rather the
public didn't notice.
Nicholas Clark
Randal L. Schwartz
Nicholas> I realise that it looks somewhat silly if perl ships with
Nicholas> modules that are slightly out of date. But it looks stupid
Nicholas> if perl ships with modules that are broken, and it's highly
Nicholas> visible if a new "stable" release comes alone shortly after
Nicholas> to fix them, advertising the very cock up we'd rather the
Nicholas> public didn't notice.
I can support your decision. However, as an additional data point, I
installed the versions in question the day they were CPANed, and used
them against bleadperl as it was continually updated.
We really need a better mechanism to prevent what just happened though.
Pumpkings should have on their checklist:
[ ] Two weeks before RC1, fold in all out-of-date CPAN modules
Or something. Can we add that to FAQ somewhere? (half smiley)
Please, I respect you as a volunteer. I'm only being an advocate
for the masses who will install this update, only to have to reinstall
a half dozen pieces of core immediately. Like I kept doing on every
bleadperl. :)
H.Merijn Brand
> >>>>> "Nicholas" == Nicholas Clark <ni...@ccl4.org> writes:
>
> Nicholas> I realise that it looks somewhat silly if perl ships with
> Nicholas> modules that are slightly out of date. But it looks stupid
> Nicholas> if perl ships with modules that are broken, and it's highly
> Nicholas> visible if a new "stable" release comes alone shortly after
> Nicholas> to fix them, advertising the very cock up we'd rather the
> Nicholas> public didn't notice.
>
> I can support your decision. However, as an additional data point, I
> installed the versions in question the day they were CPANed, and used
> them against bleadperl as it was continually updated.
>
> We really need a better mechanism to prevent what just happened though.
>
> Pumpkings should have on their checklist:
>
> [ ] Two weeks before RC1, fold in all out-of-date CPAN modules
>
> Or something. Can we add that to FAQ somewhere? (half smiley)
>
> Please, I respect you as a volunteer. I'm only being an advocate
> for the masses who will install this update, only to have to reinstall
> a half dozen pieces of core immediately. Like I kept doing on every
> bleadperl. :)
And the masses (and maybe you too) are still used to the old release cycles
Nick has chosen to do a quarterly release, which should be more than enough to
give time for module updates to go through blead and backport/integrate to
maint. If someone is eager to have the most recent, either fetch from CPAN, or
wait 3 month to get it in the next.
I still think it is a very sane strategy that Nick is following, and the blead
committers could be more vivid in updating dual-life modules to core than we
currently do, but we also need signals.
So now that *you* know what the release cycle is, maybe signal p5p every 2
month with your (very good) list of out-of-sync modules, and /we/ (p5p
committers) integrate them to blead, after which Nick integrates them to maint
deal?
--
H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/)
using perl-5.6.1, 5.8.3, & 5.9.x, and 806 on HP-UX 10.20 & 11.00, 11i,
AIX 4.3, SuSE 9.0, and Win2k. http://www.cmve.net/~merijn/
http://archives.develooper.com/daily...@perl.org/ per...@perl.org
send smoke reports to: smokers...@perl.org, QA: http://qa.perl.org
Nicholas Clark
> minor, stable things can go in. In turn, the policy of time based releases
> is specifically designed to prevent the mad rush of patching that used to
> happen just before a stable release - a mad rush of patching being the least
> conducive thing to code stability.
Actually, that's also why I'm making no great effort to remind anyone of
the code freeze dates. Suggesting that these dates are deadlines to get
things done by will encourage bursts of change close to release. Not making
any big deal of the times close to release should encourage change to be
spread more evenly over time. Avoiding clustering of changes makes it
easier to locate the cause of any problems, given that the machines running
smoke tests always start new smokes at the same rate (of time) independent of
the rate (of change).
The underlying driver of all this is that I'm trying to achieve as much
decoupling as possible between development (bug fixing and improvements)
from releasing.
Nicholas Clark
Randal L. Schwartz
H> So now that *you* know what the release cycle is, maybe signal p5p
H> every 2 month with your (very good) list of out-of-sync modules,
H> and /we/ (p5p committers) integrate them to blead, after which Nick
H> integrates them to maint
I had formerly sent announcements to this list about every month or
two as I became "annoyed" with the update list. The feedback I got
was that my postings were not welcome, so I stopped doing that, but
wanted to make sure to do it for final release. When I saw the RC1
announcement, that was my trigger. I'm not a very smart person... I
would have needed more notice and presence of mind to do it two weeks
earlier.
That's why I think it should be on the pumpking's list, not mine.
Especially since the freeze date (for folding in CPAN modules) is
apparently a pumpking decision, not mine.
H> deal?
Back at ya.
Randal L. Schwartz
Nicholas> Actually, that's also why I'm making no great effort to
Nicholas> remind anyone of the code freeze dates. Suggesting that
Nicholas> these dates are deadlines to get things done by will
Nicholas> encourage bursts of change close to release.
This would suggest that I should simply adopt a policy to download
bleadperl about once a week, put it on my system, and see what CPAN
modules are out of sync, and announce it every time I notice it.
If that's OK with everyone (I got pushback before), I'll be happy
to start doing this again.
Rafael Garcia-Suarez
> >>>>> "Nicholas" == Nicholas Clark <ni...@ccl4.org> writes:
>
> Nicholas> Actually, that's also why I'm making no great effort to
> Nicholas> remind anyone of the code freeze dates. Suggesting that
> Nicholas> these dates are deadlines to get things done by will
> Nicholas> encourage bursts of change close to release.
>
> This would suggest that I should simply adopt a policy to download
> bleadperl about once a week, put it on my system, and see what CPAN
> modules are out of sync, and announce it every time I notice it.
>
> If that's OK with everyone (I got pushback before), I'll be happy
> to start doing this again.
FWIW there's a script in bleadperl, Porting/corecpan.pl, that does
this check -- in both ways (it also reports modules that are
newer in the core than on the CPAN.)
The fact that a module is newer on the CPAN doesn't mean that it should
be upgraded immediately, though. Filter::Simple and I18N::LangTags
fail some tests when integrated in blead. I haven't had time to
investigate these though.
H.Merijn Brand
> >>>>> "Nicholas" == Nicholas Clark <ni...@ccl4.org> writes:
>
> Nicholas> Actually, that's also why I'm making no great effort to
> Nicholas> remind anyone of the code freeze dates. Suggesting that
> Nicholas> these dates are deadlines to get things done by will
> Nicholas> encourage bursts of change close to release.
>
> This would suggest that I should simply adopt a policy to download
> bleadperl about once a week, put it on my system, and see what CPAN
> modules are out of sync, and announce it every time I notice it.
>
> If that's OK with everyone (I got pushback before), I'll be happy
> to start doing this again.
make that a two week period, and count me in. But there's more than just me
Steve Hay
applied to bleadperl, but when it was integrated into maint-5.8 (by
change 22611), part of it seems not to have been applied.
The attached patch for maint-5.8 corrects this.
- Steve
------------------------------------------------
Radan Computational Ltd.
The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.
Nicholas Clark
> I've found a minor nit in 5.8.4-RC1 on Win32: change 22610 was correctly
> applied to bleadperl, but when it was integrated into maint-5.8 (by
> change 22611), part of it seems not to have been applied.
>
> The attached patch for maint-5.8 corrects this.
The repository browser seems to think that that line is already as you've
patched it (ie there is a # in there)
As does my rsync'd source tree.
I'm a bit confused.
> --- win32/makefile.mk.orig 2004-04-05 20:14:42.000000000 +0100
> +++ win32/makefile.mk 2004-04-08 09:04:40.050029600 +0100
> @@ -34,7 +34,7 @@
> # versioned installation can be obtained by setting INST_TOP above to a
> # path that includes an arbitrary version string.
> #
> -INST_VER *= \5.8.4
> +#INST_VER *= \5.8.4
>
> #
> # Comment this out if you DON'T want your perl installation to have
Nicholas Clark
Nicholas Clark
> Nicholas Clark wrote:
> >I'm a bit confused.
> >
> You're looking at the wrong file!
That would explain a lot :-)
> win32/Makefile is indeed OK; it is win32/makefile.mk which is wrong.
OK. If I follow the comments in makefile.mk correctly this will make the
versioning policy with makefile.mk be the same as that of Makefile?
Whereas in the 5.8.3 release they were not consistent, with Makefile
having that bit commented out, and makefile.mk having it active.
Nicholas Clark
Steve Hay
>On Thu, Apr 08, 2004 at 09:10:21AM +0100, Steve Hay wrote:
>
>
>>I've found a minor nit in 5.8.4-RC1 on Win32: change 22610 was correctly
>>applied to bleadperl, but when it was integrated into maint-5.8 (by
>>change 22611), part of it seems not to have been applied.
>>
>>The attached patch for maint-5.8 corrects this.
>>
>>
>
>The repository browser seems to think that that line is already as you've
>patched it (ie there is a # in there)
>
>http://public.activestate.com/cgi-bin/perlbrowse?file=%2F%2Fdepot%2Fmaint-5.8%2Fperl%2Fwin32%2FMakefile&blame=1
>
>As does my rsync'd source tree.
>
>I'm a bit confused.
>
You're looking at the wrong file!
win32/Makefile is indeed OK; it is win32/makefile.mk which is wrong.
- Steve
>
>
>
>>--- win32/makefile.mk.orig 2004-04-05 20:14:42.000000000 +0100
>>+++ win32/makefile.mk 2004-04-08 09:04:40.050029600 +0100
>>@@ -34,7 +34,7 @@
>> # versioned installation can be obtained by setting INST_TOP above to a
>> # path that includes an arbitrary version string.
>> #
>>-INST_VER *= \5.8.4
>>+#INST_VER *= \5.8.4
>>
>> #
>> # Comment this out if you DON'T want your perl installation to have
>>
>>
Steve Hay
Correct. And the same goes for INST_ARCH too (the change to which was
correctly applied to 5.8 by change 22611.)
- Steve
Nicholas Clark
> Correct. And the same goes for INST_ARCH too (the change to which was
> correctly applied to 5.8 by change 22611.)
Fixed.
Nicholas Clark
Elizabeth Mattijsen
> http://opensource.fotango.com/~nclark/perl-5.8.4-RC1.tar.bz2
No unexpected things while making / installing on Mac OS X 10.2, nor
any unexpected issues with any of my CPAN modules.
Liz