Moved to an extra thread, so it won't get lost.

I propose the following process using the language specifications at github:d-programming-language.org.

- The language specifications are made version specific (e.g. 2.6, partly handled by tags already).

- Branches are created for the next 2(?) minor versions ahead of the current release cycle.
  Another one is created for the next major version.

- The website should have links to specifications for different versions
  which are build from the corresponding tags/branches.

- We adopt a pull based development for the language specification similar
  to that for phobos (review queue, review manager, voting).

- Specs are lined with acceptance tests. Ideally this would be the code examples.

- The compiler strives to fulfill the specs on corresponding versions.

- Specs are added to the autotester.

Not sure if github:d-programming-language.org can handle all this appropriately,
but it seems worth a try.


As a first test case someone could salvage the abbreviated delegate syntax (a => a+2).

martin

Le 04/11/2011 17:10, Martin Nowak a écrit :
> Moved to an extra thread, so it won't get lost.
>
> I propose the following process using the language specifications at
> github:d-programming-language.org.
>
> - The language specifications are made version specific (e.g. 2.6,
> partly handled by tags already).
>
> - Branches are created for the next 2(?) minor versions ahead of the
> current release cycle.
> Another one is created for the next major version.
>
> - The website should have links to specifications for different versions
> which are build from the corresponding tags/branches.
>
> - We adopt a pull based development for the language specification similar
> to that for phobos (review queue, review manager, voting).
>
> - Specs are lined with acceptance tests. Ideally this would be the code
> examples.
>
> - The compiler strives to fulfill the specs on corresponding versions.
>
> - Specs are added to the autotester.
>
> Not sure if github:d-programming-language.org can handle all this
> appropriately,
> but it seems worth a try.
>
>
> As a first test case someone could salvage the abbreviated delegate
> syntax (a => a+2).
>
> martin

I would love that ! And I'm pretty sure I'm not the only one. D definitively needs more specs.

On 04-11-2011 17:10, Martin Nowak wrote:
> Moved to an extra thread, so it won't get lost.
>
> I propose the following process using the language specifications at
> github:d-programming-language.org.
>
> - The language specifications are made version specific (e.g. 2.6,
> partly handled by tags already).
>
> - Branches are created for the next 2(?) minor versions ahead of the
> current release cycle.
> Another one is created for the next major version.
>
> - The website should have links to specifications for different versions
> which are build from the corresponding tags/branches.
>
> - We adopt a pull based development for the language specification similar
> to that for phobos (review queue, review manager, voting).
>
> - Specs are lined with acceptance tests. Ideally this would be the code
> examples.
>
> - The compiler strives to fulfill the specs on corresponding versions.
>
> - Specs are added to the autotester.
>
> Not sure if github:d-programming-language.org can handle all this
> appropriately,
> but it seems worth a try.
>
>
> As a first test case someone could salvage the abbreviated delegate
> syntax (a => a+2).
>
> martin

I hate to sound like a troll, but what we have right now hardly qualifies as a language reference. A *real* specification would be much more complicated and in-depth. I *do* think we need to develop a better, more formal specification, but this will obviously require efforts from all the people involved in the development and evolution of D.

- Alex