On 27/11/2007, Ken Williams <[EMAIL PROTECTED]> wrote:
> File::Spec in the core (and to a lesser extent, Cwd) is now
> significantly different from the CPAN release. A unified diff
> between the core code and version 3.25_01 (with standard context) is
> about 500 lines long, mostly because 3.25_01 was never integrated
> into the core, but also because recent patches have been made
> directly against the core, not the CPAN release.
Yes. 3.25_01 was not integrated into 5.10 because:
* it contains significant changes, the unified diff from 3.25 to
3.25_01 is 27ko
* it was released late in the 5.10 freezing process
* it might introduce regressions, esp. when merged with blead-only
changes
* it fixes no immediate problem in perl's test suite
> How slushy is the core code freeze? Is there room for 3.25_01 to be
> integrated?
No, it won't.
> If not, should I just wait until perl 5.10 hits the world and call
> that 3.26, and then release 3.27 shortly thereafter, with the 3.25_01
> (and subsequent) changes? There could be possible regressions if we
> do that though.
If I understand correctly, that would mean:
* call the current bleadperl PathTools source 3.26
* bleadperl's version + changes in 3.25_01 will be 3.26_01, to be
promoted to 3.27 after stabilisation
Right ? I agree with that plan.
(I think it's important for a module such as PathTools to have a CPAN
version that corresponds exactly to what is issued with a Perl release.)
Note also: we have a couple of patches pending by John Malmberg, one to
cwd.t and one to File::Spec::VMS (if I don't forget any). I think I may
apply them to bleadperl then, if noone objects.
It's a bit unfortunate that we have two repositories for PathTools, with
patches going sometimes in one, sometimes in another. We have then to
merge diffs in both directions. In my opinion, PathTools is too
entangled to the core to be developed separately, so I think that the
bleadperl repository should be considered the master one, and the svn
repository should be used mostly for convenience and local branches. I
also hope that with the upcoming switch to git, that kind of problem
will disappear, if we find a way to get CPAN releases to be developed in
branches of the main repository.
