On Monday, 22 April 2013 at 14:25:21 UTC, David Nadlinger wrote:
> On Sunday, 21 April 2013 at 19:58:14 UTC, Tourist wrote:
>> What's holding you from releasing a version now and declaring it stable for e.g. a year?
>
> What would be the benefit of just declaring one release stable?
>
> This is not a trick question.
>
> David

I have raised this topic several times already. Stable version that is guaranteed to never break user code but still receives non-breaking bug-fixes is important for corporate adoption - those will never agree to spend some tome in the middle of running project to fix some unknown breakage created by a tool.

On Tuesday, 23 April 2013 at 07:50:44 UTC, Dicebot wrote:
> I have raised this topic several times already. Stable version that is guaranteed to never break user code


So what happens when a flaw in the language is fixed?

Do you fix it and break code, or do you leave it broken?

On Tuesday, 23 April 2013 at 07:52:20 UTC, Mehrdad wrote:
> On Tuesday, 23 April 2013 at 07:50:44 UTC, Dicebot wrote:
>> I have raised this topic several times already. Stable version that is guaranteed to never break user code
>
>
> So what happens when a flaw in the language is fixed?
>
> Do you fix it and break code, or do you leave it broken?

Well we have 2.062 . Let's decide this is stable version.

2.062.1 will go out then 2.062.2, etc . . . They contains only fixes with really small (I mean almost non existent) breakage, no new feature, only fix of ICE, codegen bugs, etc . . .

And 2.063 can still be pushed in the meantime. The thing that with D, you hit compiler bugs and so on, and you can't get fixes without getting the new version that break half of your code.

On Tuesday, 23 April 2013 at 07:52:20 UTC, Mehrdad wrote:
> On Tuesday, 23 April 2013 at 07:50:44 UTC, Dicebot wrote:
>> I have raised this topic several times already. Stable version that is guaranteed to never break user code
>
>
> So what happens when a flaw in the language is fixed?
>
> Do you fix it and break code, or do you leave it broken?

Fix it in latest version. Leave it broken in stable.

On Tuesday, 23 April 2013 at 08:18:08 UTC, Dicebot wrote:
> On Tuesday, 23 April 2013 at 07:52:20 UTC, Mehrdad wrote:
>> On Tuesday, 23 April 2013 at 07:50:44 UTC, Dicebot wrote:
>>> I have raised this topic several times already. Stable version that is guaranteed to never break user code
>>
>>
>> So what happens when a flaw in the language is fixed?
>>
>> Do you fix it and break code, or do you leave it broken?
>
> Fix it in latest version. Leave it broken in stable.

I'm not convinced that's terribly useful but if you think so then ok...

On Tuesday, 23 April 2013 at 07:50:44 UTC, Dicebot wrote:
> On Monday, 22 April 2013 at 14:25:21 UTC, David Nadlinger wrote:
>> On Sunday, 21 April 2013 at 19:58:14 UTC, Tourist wrote:
>>> What's holding you from releasing a version now and declaring it stable for e.g. a year?
>>
>> What would be the benefit of just declaring one release stable?
>>
>> This is not a trick question.
>>
>> David
>
> I have raised this topic several times already. Stable version that is guaranteed to never break user code but still receives non-breaking bug-fixes is important for corporate adoption - those will never agree to spend some tome in the middle of running project to fix some unknown breakage created by a tool.

Okay, maybe it was somewhat of a trick question after all: "Tourist" put it as if all that was required was to mark a certain version stable, and I wanted to hint at the fact that this alone wouldn't help anybody at all.

David

On Tuesday, 23 April 2013 at 07:52:20 UTC, Mehrdad wrote:
> On Tuesday, 23 April 2013 at 07:50:44 UTC, Dicebot wrote:
>> I have raised this topic several times already. Stable version that is guaranteed to never break user code
>
>
> So what happens when a flaw in the language is fixed?
>
> Do you fix it and break code, or do you leave it broken?

I am more for following the C/C++ solution: periodical revise the language, but not every two months. Several years and once that the compiler infrastructure is already in place and tested, publish (officially) the new version.

During the meantime, users could live with workarounds and "forbidden to do that!". Look at C and MISRA-C.

It won't help to declare a stable version of D, while keep adding new things. What would really help is to stop adding new things, remove those that we are in doubt if they are good or no (properties?) or, at least, leave them as they are, then move towards improving the tools.

A cleaner language with better tools will allow D to take off, while still leaving room for possible improvements in future revisions.

C++ did not start as a perfect language, nor it has become, still there are tools for it, people are using it, companies are hiring C++ developers.

Being predictable does matter sometimes. Tools matter too.

On Tuesday, 23 April 2013 at 08:23:34 UTC, David Nadlinger wrote:
> Okay, maybe it was somewhat of a trick question after all: "Tourist" put it as if all that was required was to mark a certain version stable, and I wanted to hint at the fact that this alone wouldn't help anybody at all.
>
> David

Sure. If "naming" is only thing required, than anyone can name it and no D team effort is needed :) Unfortunately, it is not that simple.

It is simply impossible for D. Defining trait for C/C++ is very strict and formal standard paper which completely defines the language. Revise of standard is decoupled with compiler releases. Standard can be revised once in a 10 years but compilers keep evolving having this paper in mind.

D has reference compiler and thus you technically suggest to stop releasing any compiler version for 1-2 years. Ugh.

On Tuesday, 23 April 2013 at 08:33:05 UTC, eles wrote:
> I am more for following the C/C++ solution: periodical revise the language, but not every two months. Several years and once that the compiler infrastructure is already in place and tested, publish (officially) the new version.
>
> During the meantime, users could live with workarounds and "forbidden to do that!". Look at C and MISRA-C.
>
> It won't help to declare a stable version of D, while keep adding new things. What would really help is to stop adding new things, remove those that we are in doubt if they are good or no (properties?) or, at least, leave them as they are, then move towards improving the tools.
>
> A cleaner language with better tools will allow D to take off, while still leaving room for possible improvements in future revisions.
>
> C++ did not start as a perfect language, nor it has become, still there are tools for it, people are using it, companies are hiring C++ developers.
>
> Being predictable does matter sometimes. Tools matter too.

On Tuesday, 23 April 2013 at 08:40:16 UTC, Dicebot wrote:
>
> D has reference compiler and thus you technically suggest to stop releasing any compiler version for 1-2 years. Ugh.

No. Stop adding things.

Besides that, what's the alternative?