RE: $Win32::VERSION problem

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Moin,

"Jan Dubois" <jandactivestate.com> wrote:

>On Mon, 26 Feb 2007, Nicholas Clark wrote:
>> On Mon, Feb 26, 2007 at 09:13:03AM -0800, Jan
Dubois wrote:
>> > Yes, and the forwarder() function (now in
ext/Win32CORE/Win32CORE.c
>> > requires Win32 version 0.27 or later:
Therefore you will not be able
>> > to use old versions of the Win32 module with
bleadperl anymore.
>>
>> Um.
>>
>> I was working on the assumption that all the
movement/rearrangement of
>> the win32 directory, win32/ext and the Win32
modules was appropriate
>> to replicate in maint.
>>
>> But "not be able to use" doesn't seem a
good thing for maint.
>
>It is indeed a bit worrisome, and I have to admit that I
didn't even
>realize this problem before today.
>
>But assuming I re-release an otherwise unchanged
libwin32 without the
>Win32 module to CPAN would that be good enough? Or do we
imply that you
>can install any older CPAN version of a core module on
the latest
>maintenance release and it will still work?

ARG! No! This way lies madness.

As Dave already stated in the past, the home and primary
developmen of 
dual-lived modules is blead. Putting them on CPAN serves
only two purposes:

* so people of current stable Perls can get them earlier and
not have to 
wait for the next stable release to get bugfixes and new
features
* get the into more wide spread testing of CPAN-testers

Consider this a bonus. (The alternative is that everybody
has to wait for 
the next stable Perl to get the bugfixes and new features).

Now, there are some developers here who also take this as
their personal 
quest that these dual-lived modules should install on any
old Perl 
possible - while others like me consider this somewhat
wasted resources and 
draw the line for much newer Perls (e.g. something more sane
like 5.6.2, 
which itself is quite ancient, whereas others consider 5.005
still "needs 
to be supported").

This is of course just a personal matter, and everyone is
welcome to support 
any *the newest version* of their dual-life module on any
old Perl version 
they see fit.

However, there shouldn't be a guaruantee for anything going
back more than 
the latest stable release (this is 5.8.8). Consider yourself
lucky if it 
works on anything older (if not, patches welcome 

Of course, if such a support for older (even the latest
stable) Perls 
becomes impossible because a feature such a dual-lifed
module uses is 
available only in blead, things become very tricky. 

If you are lucky, the dual-lived module gets split into a
blead-only 
and "older-perl-only" versions. This is however
only optional. No 
guaranties. Dual-lifed modules could also be withdrawn and
put pure-core 
only any time.

Furthermore, IMO there is and should never be a guarantee
that you can also 
install OLD versions of dual-lived modules on older or newer
Perls. This 
would prevent effectively any new development or new
features in these 
modules and/or blead.

All the best,

Tels

- -- 
 Signed on Tue Feb 27 19:39:44 2007 with key 0x93B84C15.
 View my photo gallery: http://bloodgate.com/phot
os
 PGP key on http://bloodgate.com/te
ls.asc or per email.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iQEVAwUBReSJBncLPEOTuEwVAQJRAwf8DJOR5A2JmNiHWg6XBeqWclyHEQpx
tvCA
v1AnNSJzTKhNSF116JzriaDzAlW5ozQAApgdW5B7UM3HFqRWrYRDShUjcjMa
eqCA
FrBumd3Yq1jDUy0oAJiG6qD00Y8qHlikUfc7nnnvX9z7Tpc6nhJfTzhzafA2
TpG1
eDxxM0UKWHnHp7LpfAwjdRoMTHBcdAZqJev7lSJ+/iQIoy773w3cKbME7y65
FvhG
6GicE+V5xjMI7lCPUQc+rMt/EAPSOPMUYh12SwKW5y6hxcs0RkiBEVS0it7+
3iW4
HgIUNWGOFN0n5GnlTZSdmZfXvN0kEq6IYoOlT6lIsS7zP+o1KetQ+g==
=2e+t
-----END PGP SIGNATURE-----

Tels wrote:
> As Dave already stated in the past, the home and
primary developmen of
> dual-lived modules is blead. Putting them on CPAN
serves only two
> purposes:
>
> * so people of current stable Perls can get them
earlier and not have to
> wait for the next stable release to get bugfixes and
new features
> * get the into more wide spread testing of
CPAN-testers
>
> Consider this a bonus. (The alternative is that
everybody has to wait for
> the next stable Perl to get the bugfixes and new
features).

Perhaps this is how it actually plays out most of the time,
but
Porting/Contract has a very different take.  In the case
under
consideration, Win32API::File, removing the indirect object
syntax
seemed to me something better done by way of the module
owner(s)
rather than in bleadperl.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Moin,

On Tuesday 27 February 2007 22:33:07 Yitzchak Scott-Thoennes
wrote:
> Tels wrote:
> > As Dave already stated in the past, the home and
primary developmen of
> > dual-lived modules is blead. Putting them on CPAN
serves only two
> > purposes:
> >
> > * so people of current stable Perls can get them
earlier and not have
> > to wait for the next stable release to get
bugfixes and new features *
> > get the into more wide spread testing of
CPAN-testers
> >
> > Consider this a bonus. (The alternative is that
everybody has to wait
> > for the next stable Perl to get the bugfixes and
new features).
>
> Perhaps this is how it actually plays out most of the
time, but
> Porting/Contract has a very different take.  In the
case under
> consideration, Win32API::File, removing the indirect
object syntax
> seemed to me something better done by way of the module
owner(s)
> rather than in bleadperl.

Guess I should have read that document - didn't even knew it
existed. Which 
somehow really questions my ability to maintain core Perl
modules.  Thanx 
for pointing that out!

Btw, the confusion arises because I considered only modules
that are "taken" 
from the core and then "released into the wild"
(aka CPANed).

The other way, where a module exists on CPAN first and is
then added to the 
core - well, I think there the creator(s) of the module
should have a much 
bigger say, which Porting/Contract probably spells out much
more elaborate 
then I ever could :-D

Take care,

Tels

- -- 
 Signed on Tue Feb 27 23:58:18 2007 with key 0x93B84C15.
 Get one of my photo posters: http://bloodgate.com/pos
ters
 PGP key on http://bloodgate.com/te
ls.asc or per email.

 "Den wahren Wert dieser Software werden vermutlich nur
Fach Läute und
 Firmen erkennen."

  -- "So isst es. Ein gewißer Standart muss schon
gewart beiben!" --  Kabe 
(http://tinyurl.com/3kucx
)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iQEVAwUBReTGXHcLPEOTuEwVAQKREQf+IofcUxjrrnZoVqffTZndRHJ8YpVd
KqjD
Y2fzURQwT8hZA6ropfHmt9rbAOR1ALPPuVRX2svnetVURPr11OvNPSRHT1nn
iZ9M
GIvOutS97zrrnoUrSjl01LA+ZaVg/7OvT4C77vU1lpXmITG539qJeotj/mNN
PzK6
rv7rWHHy0Zloxlo0goswAwffClVRavcqTuAiDRpokwkV+HLiqCtzeW83FS+H
AzM+
ZH3KASbpXHxhjxqEP4ROkjeo8Inz3889U0H09igyZBEL5Qkb3V3vlrMl2OKX
BFx7
hkJcC9BuZc7B0eUedF39sztYb8Mhpq7l7Zz3Cs0r1THIbFK7dgFyPg==
=3+or
-----END PGP SIGNATURE-----

Yitzchak Scott-Thoennes wrote:
> Tels wrote:
>> As Dave already stated in the past, the home and
primary developmen of
>> dual-lived modules is blead.

Uh, what?  No.  As far as I'm concerned the home and primary
development of
Test-Simple is CPAN.  I'd say the same thing about
ExtUtils-MakeMaker but I
think that would be overstepping my bounds as I am not the
original author.


>> Putting them on CPAN serves only two
>> purposes:
>>
>> * so people of current stable Perls can get them
earlier and not have to
>> wait for the next stable release to get bugfixes
and new features
>> * get the into more wide spread testing of
CPAN-testers

That's a very narrow view leaving off the many benefits of
decoupling
development from the core.

* The module can be developed without worrying if a failure
is the result of
bleadperl or a change in the module.  (This is one of the
main reasons I
pulled MakeMaker out, oh god the File::Find and VMS bugs).

* The module can be worked on independently without having
to know how to
develop bleadperl (consider Joe Perl User who wants to patch
a module).

* Changes to individual modules can be seen and tracked by
users as opposed
to having to grovel through a monolithic Changes file for
the entire Perl
distribution.

* Bugs for individual modules can be tracked and seen
separate from the bugs
in other modules or in perl.

* There is a distinct person (or group of people) who has
oversight/concern/ownership/responsibility over the code to
steer its
development and make sure it actually works.  p5p, being
effectively a large
committe, and having so many modules, along with perl
itself, to deal with
cannot provide such personal attention.

* Rather than the module adjusting itself to new bugs and
quirks in
bleadperl, the modules serve to find new bugs and quirks. 
All of CPAN does
this but the dual-lifed modules are explicitly run as part
of the bleadperl
tests and thus provide day-to-day coverage.

* Vendors who package perl (Fedora, Debian, etc...) can more
easily track
and provide incremental upgrades to core modules without
having to track and
pick out the changes from bleadperl and wonder if the new
code is backwards
compatible.

On 2/27/07, Yitzchak Scott-Thoennes <sthoennaefn.org> wrote:
> Tels wrote:
> > As Dave already stated in the past, the home and
primary developmen of
> > dual-lived modules is blead. Putting them on CPAN
serves only two
> > purposes:
> >
> > * so people of current stable Perls can get them
earlier and not have to
> > wait for the next stable release to get bugfixes
and new features
> > * get the into more wide spread testing of
CPAN-testers
> >
> > Consider this a bonus. (The alternative is that
everybody has to wait for
> > the next stable Perl to get the bugfixes and new
features).
>
> Perhaps this is how it actually plays out most of the
time, but
> Porting/Contract has a very different take.  In the
case under
> consideration, Win32API::File, removing the indirect
object syntax
> seemed to me something better done by way of the module
owner(s)
> rather than in bleadperl.

I am one of the maintainers, and I would rather backport
blead changes
than the other way around. More peopl eare likely to test
and patch
the blead version than the cpan version (just due to
self-selection,
people on p5p are highly likely to be inclined to post
patches, and
Ill see them there.)

Yves

-- 
perl -Mre=debug -e "/just|another|perl|hacker/"

On Tue, Feb 27, 2007 at 07:39:49PM +0000, Tels wrote:
> As Dave already stated in the past, the home and
primary developmen of 
> dual-lived modules is blead. Putting them on CPAN
serves only two purposes:

Um no, that's not what I said (or at least meant 

Modules that started off in CPAN, then got bundled into
core, but which
continue being principally maintained by their author,
should carry on
having their main home on CPAN, with bleed syncing from time
to time.

I was objecting to a module that principally lived in and
was developed in
bleed, one that I was heavily involved with, being rehomed
to
CPAN so I could no longer directly apply my changes to
bleed.

-- 
A walk of a thousand miles begins with a single step...
then continues for another 1,999,999 or so.

demerphq wrote:
>> Perhaps this is how it actually plays out most of
the time, but
>> Porting/Contract has a very different take.  In the
case under
>> consideration, Win32API::File, removing the
indirect object syntax
>> seemed to me something better done by way of the
module owner(s)
>> rather than in bleadperl.
> 
> I am one of the maintainers, and I would rather
backport blead changes
> than the other way around. More peopl eare likely to
test and patch
> the blead version than the cpan version (just due to
self-selection,
> people on p5p are highly likely to be inclined to post
patches, and
> Ill see them there.)

My experience with MakeMaker and Test::More have been the
other way around.
 I get most of my patches via rt.cpan.org.

I also don't want to have to backport blead changes
especially if I try to
maintain backwards compat further back than 5.8.  I'd rather
the patches
were written in the first place with compatibility in mind
then having to
backport it (with the possibility that it cannot be back
ported).

And then blead has to be repatched with the backported
version and the
inevitable conflicts which will make the merger's life more
difficult.

Finally, now as a CPAN author I have to track changes in
bleadperl to look
for changes in my module.  In inevitably miss some.  Now the
person merging
my CPAN version into bleadperl must be diligent and make
sure I didn't miss
and possibly revert a fix in bleadperl.

That said, it would be nice if bleadperl treated CPAN
modules like you would
any other vendor code out of your control.  That being you
have a "vendor"
branch for each dual-lifed module.  Then you have a local
branch of that.
You patch up the local branch.  The code in the local branch
is what gets
merged into the trunk.  When a new version is released on
CPAN it is
committed to the vendor branch and the changes pulled into
and merged with
the local branch.  A diff between the vendor and local
branch continues to
show where the local and vendor versions are different.  You
can look
through the log of the local branch and compare with the
vendor changes file
to see what has and has not been accepted.  I, as the
author, can look at
your local branch of my module to find the changes.  You can
even set up
automatic emails to the author for each change.

And most of the problems with dual-lifed modules just goes
away.

This is standard issue vendor branching, I do it all the
time when I patch
CPAN code.  I even do it with bleadperl since the repository
is so damned
hard to get at.  And decent, modern version control system
supports it.  In
SVK its just...

    cd CPAN-Module-0.11
    svk import //vendor/CPAN-Module -m 'CPAN-Module 0.11
from CPAN'
    svk cp //vendor/CPAN-Module //local/CPAN-Module -m
'Local copy'
    svk co //local/CPAN-Module ~/work/CPAN-Module

If a new version of CPAN-Module comes out its...

    cd CPAN-Module-0.12
    svk import //vendor/CPAN-Module -m 'CPAN-Module 0.12
from CPAN'
    cd ~/work/CPAN-Module
    svk pull

I'm sure git has something similar.  Perforce and CVS not so
much.
Subversion has various hacks to work around its lack of good
branch
management (svnmerge).

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Moin,

On Wednesday 28 February 2007 00:46:15 Dave Mitchell wrote:
> On Tue, Feb 27, 2007 at 07:39:49PM +0000, Tels wrote:
> > As Dave already stated in the past, the home and
primary developmen of
> > dual-lived modules is blead. Putting them on CPAN
serves only two
> > purposes:
>
> Um no, that's not what I said (or at least meant 
>
> Modules that started off in CPAN, then got bundled into
core, but which
> continue being principally maintained by their author,
should carry on
> having their main home on CPAN, with bleed syncing from
time to time.
>
> I was objecting to a module that principally lived in
and was developed
> in bleed, one that I was heavily involved with, being
rehomed to
> CPAN so I could no longer directly apply my changes to
bleed.

Yes, sorry, I overlooked the other direction modules could
go.

Best wishes,

Tels



- -- 
 Signed on Wed Feb 28 19:03:19 2007 with key 0x93B84C15.
 Get one of my photo posters: http://bloodgate.com/pos
ters
 PGP key on http://bloodgate.com/te
ls.asc or per email.

 "Yeah. Whatever."

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iQEVAwUBReXSF3cLPEOTuEwVAQIAJwf6AmtU7w+F98QU6IJLIk8FlXh6QApA
5gdc
qOi4DTG4ucJmRwfQlVtudR3yer5cC037qnnt47ulOF1zJQKroC7xnM8IinL2
10jG
cPxxXY3cx8IRjosWDjf9ZLMmkVMlN9ajqye9/STXbzvlC6CrEeH6CzPsO/g9
izAN
Dkt+Y7j22K97d0KWvrJCkzUz5jRkUfnn/FnloPr6fus0EZGDewQFKYw/Q03l
wpsP
psFvWPY0uTAzjt7vZkPC+jKr81/6in8ykDFwjLweZe5ZcnEYYs7iUGHwQm3q
dUge
cqHFZ4/wji/szRRqy89a1w1IXmibTR0jZO3lMar3fMMGu4d7r7kW+A==
=Ca9n
-----END PGP SIGNATURE-----