* Daniel Carrera (daniel.carr...@theingots.org) [090528 16:07]:
> Mark Overmeer wrote:
>> In March 2006, Sam Vilain and I started to think about a new CPAN
>> what we named CPAN6. There is a lot of information about the project on
>> http://cpan6.org
>
> I know about CPAN6, thanks. It's come up a couple of times on IRC.
> Perhaps you could hang out on the IRC channel so we don't have different
> people going off in different directions with CPAN.
It's not a discussion like "let's make a change to the current set-up",
so IRC doesn't seem to me a good spot to discuss it. I gave various
talks on YAPC's and interviewd a few of the CPAN maintainers. Workshops,
Hackathons and YAPCs are more suitable.
Trying to keep-up with normal email is already a daily struggle. Besides,
having 9 hours time-difference with the West Coast doesn't help: when they
wake-up at 8, I am just getting my 2 yr old son from Kindergarten back home.
And when he finally sleeps, I am tired ;-)
>>> A) Can we add "version", "target" flags to CPAN metadata? I was
>>> thinking that current modules would all be version=1 and
>>> target=perl5.
>>
>> CPAN does not have an official concept of version numbers on distributions,
>> but only on the pm files which are inside the distribution.
>
> I know, thanks. I was suggesting a change.
I had a discussion of two days about "versions" with Sam Vilain. What
we came up with, is that there is only one solution: versions need to
be strings without meaning. Of course, you can help yourself using some
kind of logic sequencing these strings, but everyone has different ideas
about how to do that. Who (besides Perl people) expect 5.10 after 5.8?
The solution is simple: each release has a unique version string. The
release also lists as meta-data what kind of follow-up it is to which
existing release. For instance:
5.10.0 diverts from 5.8.8 (upgrade)
5.8.9 replaces 5.8.8 (update)
5.10.1-blead diverts from 5.10.0 (devel)
5.10.1 replaces 5.10.0 and 5.10.1-blead (merge)
In upgrade paths, replacements are safe upgrades and diversion may break
code interfaces, where upgrades need more care (and probably explicit
user approval)
Which this approach, you can safely create all the weird versioning needs
that Perl6 has designed.
A picture could be presented to the users, to help making choices:
|
5.8.8
| \
| \
5.8.9 5.10.0
| \
| \
| 5.10.1-blead
| /
5.10.1
>>> D) In addition to target=perl5 and target=perl6 we could have target=parrot.
>>
>> IMO, we need many more. What you call "target" is actually a namespace.
>> The current CPAN archive has only one target.
>
> Target, namespace, same difference. It's an identifier to divide modules
> into categories.
Well... do you need all archives to share one infrastructure? I think it
is nicer to have people being able to open-up CPAN-like archives with
additional features. For instance, if someone wants to publish pre-compiled
PIR versions of modules, then s/he should not need the assistence of the
core CPAN. With an URI namespace, you address an archive where you can
find the data. A part of that namespace (URI fragment) could be a target
within the archive.
>>> F) In summary, we have a possible course of action:
>> There is a lot more structurally problematic. Please read one of my
>> papers on the cpan6.org website.
> I have scanned through the first one. It's 30 pages...
Oh, that's the small one.
--
MarkOv
------------------------------------------------------------------------
Mark Overmeer MSc MARKOV Solutions
m...@overmeer.net soluti...@overmeer.net
http://Mark.Overmeer.net http://solutions.overmeer.net
