On 20/07/2015 7:12 p.m., Andrea Fontana wrote:
> On Monday, 20 July 2015 at 04:45:21 UTC, Rikki Cattermole wrote:
>>> Perhaps we should name this 2.100, to signify such a milestone.
>>
>> Or instead, move to SEMVER? Same effect.
>> Although, now might be a good time to think about D3. After all, we
>> are having a massive change in the ecosystem. It wouldn't be that
>> strange to think of it as more of a push for polishing.
>
> Semver ftw! About D3: if we have to do a switch, it's the right time to
> remove old things left for retro-compatibility and rename/move things
> (and fix @property, for example).

In a way we are in a transition period. Not a big language change, but a ecosystem/organization one.

>>> 2.101+ -
>>> 1. Take advantage of D features to improve quality.
>>
>> As a library perhaps?
>
> +100 for library
>
>>> 6. Convert the back end to D as well.
>>
>> Ooo, yes please.
>> Perhaps even as a library?
>
> +100
>

On Monday, 20 July 2015 at 07:15:16 UTC, Adrian Matoga wrote:
> On Monday, 20 July 2015 at 04:02:04 UTC, Walter Bright wrote:
>> 2.069 - translate to D. No new features, no refactoring. Only regression fixes and what's already in HEAD. This should give us a solid baseline. It also means that open PRs that address other issues will not be pulled for 2.069.
>>
>> Perhaps we should name this 2.100, to signify such a milestone.
>
> This may also be the best moment to start keeping frontend versions among DMD/GDC/LDC synchronized, forever.

So much this.

Theres always so many nice new features in the newest dmd (and phobos) that you want to use it, but cant as a result of GDC/LDC being slightly outdated.

On Monday, 20 July 2015 at 04:35:30 UTC, Walter Bright wrote:
> But I view the backend license encumbrance as more of a theoretical issue than a practical one - the license is extremely permissive. There isn't that much more to it than agreeing to not sue Symantec.

Redistribution is explicitly disallowed though (i.e. one can't fork it on github without individual permission).

On Monday, 20 July 2015 at 08:40:24 UTC, Kagamin wrote:
> Redistribution is explicitly disallowed though (i.e. one can't fork it on github without individual permission).

Technically, I believe that by uploading any project to GitHub, one has granted permission for it to be forked _on GitHub_.  (This is explicitly stated in the GitHub Terms of Service.)

That doesn't automatically grant any other permissions of re-use or redistribution, though.

On 20 July 2015 at 06:02, Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> 2.068 - resolve remaining regressions and release
>
> 2.069 - translate to D. No new features, no refactoring. Only regression fixes and what's already in HEAD. This should give us a solid baseline. It also means that open PRs that address other issues will not be pulled for 2.069.
>
> Perhaps we should name this 2.100, to signify such a milestone.
>
> 2.101+ -
> 1. Take advantage of D features to improve quality.
> 2. Go to full lazy semantic analysis of imports, rather than the current
> "analyze them all"
> 3. Rethink what "speculative instantiation" of templates means so we can
> have a coherent process of compiling them.
> 4. Redo CTFE interpreter so it only rarely needs to allocate memory. This
> was already done for constant folding, but now it's time for the rest of the
> interpreter.
> 5. Get rid of reliance on the global error count. This has been mostly done,
> it just hast to be finished.
> 6. Convert the back end to D as well.

I just have one request.  We need to designate a supported version of the compiler (2.069?) as the base to which we convert and maintain compatibility for, and do not introduce any new features after that point.  Something as vague as "the last three versions" does *not* cut it.

This is to give maximum time for all ecosystems to adjust, and encourage that we have a "stable" snapshot of D2 before the conversion that will receive maintenance fixes long after mainline development has switched.

Iain

On 7/20/2015 1:40 AM, Kagamin wrote:
> On Monday, 20 July 2015 at 04:35:30 UTC, Walter Bright wrote:
>> But I view the backend license encumbrance as more of a theoretical issue than
>> a practical one - the license is extremely permissive. There isn't that much
>> more to it than agreeing to not sue Symantec.
>
> Redistribution is explicitly disallowed though (i.e. one can't fork it on github
> without individual permission).

Yeah, well, I've never denied anyone permission, and the only point of that is they have to agree not to sue Symantec.

On 7/20/2015 2:09 AM, Iain Buclaw via Digitalmars-d wrote:
> I just have one request.  We need to designate a supported version of
> the compiler (2.069?) as the base to which we convert and maintain
> compatibility for, and do not introduce any new features after that
> point.  Something as vague as "the last three versions" does *not* cut
> it.
>
> This is to give maximum time for all ecosystems to adjust, and
> encourage that we have a "stable" snapshot of D2 before the conversion
> that will receive maintenance fixes long after mainline development
> has switched.

We can do that for 2.068.

Good intentions. Totally insane versioning scheme.

On Monday, 20 July 2015 at 04:02:04 UTC, Walter Bright wrote:
> 2.068 - resolve remaining regressions and release
>
> 2.069 - translate to D. No new features, no refactoring. Only regression fixes and what's already in HEAD. This should give us a solid baseline. It also means that open PRs that address other issues will not be pulled for 2.069.

I like this idea.

> Perhaps we should name this 2.100, to signify such a milestone.

But hate version jumps.

On Monday, 20 July 2015 at 04:02:04 UTC, Walter Bright wrote:
> Perhaps we should name this 2.100, to signify such a milestone.

2.1 Sounds good!

But going forward can we stick to a sane versioning system like what dub uses:

http://semver.org/