Just noticed this:
$ bleadperl -e 'use 5.10.1'
Feature bundle "5.10.1" is not supported by Perl 5.11.0 at -e line 1
BEGIN failed aborted at -e line 1.
BEGIN failed aborted at -e line 1.
We need to future proof this.

Hi Rafael,

Rafael Garcia-Suarez wrote:
Just noticed this:

$ bleadperl -e 'use 5.10.1'
Feature bundle "5.10.1" is not supported by Perl 5.11.0 at -e line 1
BEGIN failed aborted at -e line 1.
BEGIN failed aborted at -e line 1.

We need to future proof this.

Let me assume that there will never be a feature in 5.10.X that is not
in 5.11 (or 12 for that matter), but this is obvious. Furthermore, there
must never be a feature from 5.12 backported to 5.10.X once 5.12.0 is
out. If that assumption doesn't hold, then I don't think it's possible
future proof this at all. Why? Simple:

In chronological order:
- 5.12.0 is released. It has a shiny new feature "foo".
- Say 5.10.5 is released. "foo" is backported to 5.10.5.
- use feature ':5.10.5'; in 5.12.0 has no way of determining that 5.10.5
includes 'foo' because 5.10.5 wasn't out by the time 5.12.0 was released.

Basically, if 5.n+1 doesn't know about 5.n.X, then how do you
future-proof it? Just load the versions in 5.n+1 instead of those in
5.n.X assuming 5.n.X is a subset of the features of 5.n+1? If that's
what you mean by version comparison, then let me know and I'll write a
simple patch.

Dual-lived feature might help, but it's too early for me to see all the
possible nightmares associated with that.

Best regards,
Steffen

Wed, Jan 09, 2008 at 12:07:07PM +0100, Steffen Mueller wrote:

, let's assume we put a feature.pm on CPAN. If anything, it could
just install an entirely different piece of code for every supported
perl release, even if it couldn't be done more elegantly. That way, the
tentative 5.12.0 could be taught about the features of the tentatively
newer 5.10.5 release and die with an error like

Ah, so we'd end up with

use feature 2.8 ":5.10.5";

where version 2.8 of feature.pm is the first one to know about the
features of 5.10.5?

That way, we force the user to upgrade to a newer feature.pm, so it can
give a better message why the program won't run.

Abigail

PGP SIGNATURE
Version: GnuPG v1.4.0 (GNU/Linux)

KYSGuQsUMiTqJ8VK0orsgEc=
=IfW4
PGP SIGNATURE

Steffen Mueller wrote:
Rafael Garcia-Suarez wrote:
>Just noticed this:
>>
>$ bleadperl -e 'use 5.10.1'
>Feature bundle "5.10.1" is not supported by Perl 5.11.0 at -e line 1
>BEGIN failed aborted at -e line 1.
>BEGIN failed aborted at -e line 1.
>>
>We need to future proof this.
[]
Dual-lived feature might help, but it's too early for me to see all the
possible nightmares associated with that.

, let's assume we put a feature.pm on CPAN. If anything, it could
just install an entirely different piece of code for every supported
perl release, even if it couldn't be done more elegantly. That way, the
tentative 5.12.0 could be taught about the features of the tentatively
newer 5.10.5 release and die with an error like

"Importing feature bundle "5.10.5" is not supported by Perl 5.12.0
because 5.10.5 includes features backported from perl 5.12.1 which are
not available on 5.12.0. Alternatively try upgrading your perl or
request a feature bundle of an earlier perl 5.10 patchlevel."

Better than shipping separate feature.pm's, the information needed for
this would be a map of this sort: (I'm sure we can craft a smarter data
structure)

10 ={ # if running 5.10.X
# naturally empty since "use feature ':5.10.5';" naturally requires
5.10.5 and 5.8 didn't have feature(?).
}
12 ={ # running 5.12.X
5.10.0 =0,
5.10.1 =0,
5.10.2 =0,
5.10.3 =0,
5.10.4 =0,
5.10.5 =1, # requesting at least a patchlevel of 1 in order to
import this bundle
# no need to list all 5.12's. Same logic why the 10 =section is empty.
}
and tentatively once there is 5.14, it would include:
14 ={
# list all 5.10's and 5.12's here
}

Does this miss something except dev. versions? And apart from being
annoying to maintain?

Cheers,
Steffen

Abigail wrote:
Wed, Jan 09, 2008 at 12:07:07PM +0100, Steffen Mueller wrote:
>, let's assume we put a feature.pm on CPAN. If anything, it could
>just install an entirely different piece of code for every supported
>perl release, even if it couldn't be done more elegantly. That way, the
>tentative 5.12.0 could be taught about the features of the tentatively
>newer 5.10.5 release and die with an error like

Ah, so we'd end up with

use feature 2.8 ":5.10.5";

where version 2.8 of feature.pm is the first one to know about the
features of 5.10.5?

That way, we force the user to upgrade to a newer feature.pm, so it can
give a better message why the program won't run.

You're of course right. However, if we do nothing of the sort and start
backporting any features to a maint branch, we get the original problem
that 5.10.5 5.11.0 figuratively speaking. Don't get me wrong. I'm
brainstorming. Either way sucks.

Following up on what Dave said: If we assume 5.10.X will never have a
feature 5.11 doesn't have, then all 5.10.X feature bundles are moot
anyway because by definition, they need to be _the_same

Steffen

* Except, of course, if we add features to the 5.10.X line before the
first 5.12 release because we can fix 5.11 and aging 5.11.X snapshots
don't matter much.

Wed, Jan 09, 2008 at 02:16:18PM +0100, Steffen Mueller wrote:
Abigail wrote:
Wed, Jan 09, 2008 at 12:07:07PM +0100, Steffen Mueller wrote:
>, let's assume we put a feature.pm on CPAN. If anything, it could
>just install an entirely different piece of code for every supported
>perl release, even if it couldn't be done more elegantly. That way, the
>tentative 5.12.0 could be taught about the features of the tentatively
>newer 5.10.5 release and die with an error like

Ah, so we'd end up with

use feature 2.8 ":5.10.5";

where version 2.8 of feature.pm is the first one to know about the
features of 5.10.5?

That way, we force the user to upgrade to a newer feature.pm, so it can
give a better message why the program won't run.

You're of course right. However, if we do nothing of the sort and start
backporting any features to a maint branch, we get the original problem
that 5.10.5 5.11.0 figuratively speaking. Don't get me wrong. I'm
brainstorming. Either way sucks.

Maybe we shouldn't backport new features into the maint branch.
We now have "stable" not being 5.10.0, waiting to see what's popping
up before it earns that title. But once "stable" points to 5.10.x,
we should minimize the time that "stable" isn't the newest release
in the maint branch. Introducing new features in the maint branch
instead of focussing on bug fixes isn't going to help.

Besides, if we backport new features into maint, why have a 5.11 track?
Might as well stick everything in maint.

Abigail

PGP SIGNATURE
Version: GnuPG v1.4.0 (GNU/Linux)

zFR9nUlSYYjLrVVEwCrbeSg=
=VfA3
PGP SIGNATURE