in reply to Re^2: Will Perl 6 Replace Perl 5?
in thread Will Perl 6 Replace Perl 5?

For me it comes down to a couple questions. And I've got a feel that these are some of the actual questions many people are looking for answers for:

  1. When will Perl 6.0(.0) be stabilized?
  2. Which Perl 6.(* + 1, 2, ...) is expected to not break Perl 6.*
  3. When will the developers of the spec consider it stable enough to value back-compatibility and/or ease of upgrade over progress?
  4. When's Rakudo expected to catch up with the former?
  5. Will I be able to use the CPAN?
  6. When will I be able to use the CPAN, and how much of it?

Personally, I think I know many of the answers, but they're probably outdated because I'll personally probably be on Perl 5 unless there's either a strong access to CPAN or CPAN like functionality, or Perl 6.* is stable enough for casually writing CPAN modules without frequent breakuppage.

So, in essence, people might say "Perl 6" and not "Perl 6.0.0," because they don't know the planned versioning scheme for the specification, or the version of the specification that is planned for the above language criteria.

EDIT: Mixed up some versions in the list

Ordinary morality is for ordinary people. -- Aleister Crowley

Replies are listed 'Best First'.
Re^4: Will Perl 6 Replace Perl 5?
by Anonymous Monk on Sep 21, 2010 at 03:59 UTC

    Chromatic's whole point is there wont be a 6.0.0 ever. As a matter of fact he is telling the version number is just a farce. Rather there will monthly releases and star releases. Now we have to decide for ourselves what is stable and ready for us to use in our environments.

    Meanwhile with every monthly release bugs, get fixed, things get stable, new things get added.

    Although he is completely correct in concept, I don't it will help the Perl PR. Rather it will be a disaster

[reply]
      Chromatic's whole point is there wont be a 6.0.0 ever.

      That's not my point at all.

      As a matter of fact he is telling the version number is just a farce.

      They often are. Should you not use Test::More because it's almost a decade old and hasn't reached that mythical, magical, flying candy-flavored unicorn version number of 1.0?

      Now we have to decide for ourselves what is stable and ready for us to use in our environments.

      You've always had to decide that. Again, see Test::More.

[reply]

      I used 6.0.0 as an example. Nobody cares about the actual numbers, but about the intentions of the developers behind them. If version numbers were unimportant, we wouldn't need major and minor version releases, or mark RC's as such.

      Ordinary morality is for ordinary people. -- Aleister Crowley
[reply]
        If version numbers were unimportant....

        If version numbers were sufficient, we wouldn't label releases with "No upgrade concerns", "Source but not binary compatible", "Security fixes only", or "Don't use; only test and report any upgrade concerns, incompatibilities, build problems, or packaging woes. We also wouldn't have to explain what version numbers mean.

[reply]

In Section Meditations