Skip to content

Commit

Permalink
Simplify versioning
Browse files Browse the repository at this point in the history
  • Loading branch information
@AlexDaniel
AlexDaniel committed Aug 14, 2019
1 parent 1c2ece9 commit e4461ed
Showing 1 changed file with 5 additions and 24 deletions.
29 changes: 5 additions & 24 deletions PATH-TO-RAKU.md
View file
Expand Up @@ -23,30 +23,11 @@ to be discussed further.

## Versioning

The approach for using letters to indicate language versions will be continued
but without the mention of `6`. And uppercase letters will be used, because
mentioning `Raku D` looks much better then mentioning `Raku d`.

The `use` statement is historically used to indicate the version of the
compilation unit. Since direct code compatibility with Perl 5 is no longer
on the horizon, it seems like a good opportunity to remove any ambiguity
from the `use` statement by moving that functionality to the `unit` statement.

unit :ver<D>; # same as "use v6.d;"
unit :lang<Perl5>:ver<30>; # if we have direct support for Perl 5.30

Some kind of API should be conceived to actually hand the rest of the code
of the compilation unit to another interpreter, so that the above :lang<Perl5>
case could possibly be handled by `Inline::Perl5`. And allow support for
other languages, e.g. `:lang<Python>` to be handed over to `Inline::Python`.

Also, this would allow to specify compiler versions as well, although that
might be a compiler specific feature:

unit :release<2019.07>; # release 2019.07 or higher

Compilers would be free to either ignore additional named parameters, or
warn about named parameters they do not understand.
Because the next language release (6.e) will not coincide with
the rename, no changes to versioning of the language need to be done.
Given we are no longer forced to have "6" in the version, there are now
more options to do language versioning properly, and this aspect will
need to be discussed separately.

This comment was marked as outdated.

Sign in to view

Copy link
@vrurg

vrurg Aug 14, 2019

Contributor

I don't see why 6. must go away. As far as I remember, raku in rakudo came as a consonant to roku which is 6. This would also be a way to keep Raku's DNA.

Switching to uppercase letters though coincide with rakudo/rakudo#3112 which is yet to be accepted, but proposes CORE::<uppercase-revision>:: namespace.

This comment was marked as outdated.

Sign in to view

Copy link
@AlexDaniel

AlexDaniel Aug 14, 2019

Author Member

@vrurg So, I see it like this. Currently we don't have proper versioning of the language, and instead we use -errata branches (which are changing all the time, even if the fixes are minor). That doesn't sound right to me, especially if we subscribe to the idea that there could be more than one implementation. So in the end we might need minor versions, or something, and I don't like any short-sighted attempts to change the situation without taking other things into account. As for the letters, if we do something like 6.d.2, then question is why not just go full semver, and if so, then why are we using letters at all (even if it's allowed by semver, nobody really does it the way we do).

This comment was marked as outdated.

Sign in to view

Copy link
@vrurg

vrurg Aug 14, 2019

Contributor

This turns into a wider discussion. I'll open a new topic on this.

## Documentation changes

Expand Down

0 comments on commit e4461ed

Please sign in to comment.