July 15, 2012
On Sat, 14 Jul 2012 16:56:50 -0700, Walter Bright <newshound2@digitalmars.com> wrote:

> On 7/13/2012 9:58 AM, Jonathan M Davis wrote:
>> All that being the case, I don't know what this proposal actually buys us.
>
> I tend to agree.
>

If this was the case; 2.059 would not be three months old with no 2.060 in the immediate future.

Not having that situation is what this buys us.

I believe that there IS a problem here. There are people who, for various reasons, cannot use Git HEAD, and they have open problems. They are stuck. I believe that is the unstated impetus for this thread.

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/
July 15, 2012
On 2012-07-14 20:42, Adam Wilson wrote:
> On Sat, 14 Jul 2012 16:56:50 -0700, Walter Bright <newshound2@digitalmars.com> wrote:
>
>> On 7/13/2012 9:58 AM, Jonathan M Davis wrote:
>>> All that being the case, I don't know what this proposal actually buys us.
>>
>> I tend to agree.
>>
>
> If this was the case; 2.059 would not be three months old with no 2.060 in the immediate future.
>
> Not having that situation is what this buys us.
>
> I believe that there IS a problem here. There are people who, for various reasons, cannot use Git HEAD, and they have open problems. They are stuck. I believe that is the unstated impetus for this thread.

+1

pls make a fresh build available on a weekly or at least biweekly basis, just with regressions fixed.

July 15, 2012
On 15/07/2012 01:56, Walter Bright wrote:
> On 7/13/2012 9:58 AM, Jonathan M Davis wrote:
>> All that being the case, I don't know what this proposal actually buys
>> us.
>
> I tend to agree.
>

After 10 years of D, nothing stable still exists. We may call 2.059 stable, but frankly, it isn't.

This have a lot to do with the fact that new feature are included (with news bugs) in the same stream of version than bug fixes. In other terms, bug are fixed but at the same time, bugs are added with new features.

The natural result is that D is not stable yet, and never will be as long as the same process is used.

The proposed versioning system solve that problem. It doesn't matter if that very system is chosen in fact, but the current one is certainly not the one D needs.
July 15, 2012
There is one thing missing from developers perspective as far D is concerned: Not all D users want to be beta testers. But they are all treated in such a way.

That is reason #1 I migrate away from D all my software. It is long process and tough decision, but after 5 years of tracking D story I am fed up and I see nothing has changed and it will probably stay like that in foreseeable future.

July 15, 2012
On Thursday, 12 July 2012 at 17:20:32 UTC, deadalnix wrote:
> On 12/07/2012 19:10, Tobias Pankrath wrote:
>>> The system adopted in PHP works with a 3 number version. The first
>>> number is used for major languages changes (for instance 4 > 5 imply
>>> passing object by reference when it was by copy before, 5 > 6 switched
>>> the whole thing to unicode).
>>>
>>> The second number imply language changes, but either non breaking or
>>> very specific, rarely used stuff. For instance 5.2
>>> > 5.3 added GC, closures and namespace which does not break
>>> code.
>>
>>
>> We can also learn from the python community, whose from __future__
>> import <feature> facility is a great success and we should adopt a
>> similar scheme.
>>
>> Consider the -property switch or a future introduction of tuple syntax.
>> If you start a new project, it's no problem. Just use the switch and don't
>> introduce things that will not work without. But if you have an old
>> codebase
>> but want to use a new feature you can either
>>
>> a) fix the hole codebase at one
>> b) fix and configure your build systems to build some files with and
>> some files without the switch.
>>
>> Both options are PITA. An alternative is to introduce #pragma(future,
>> tuplesyntax);
>>
>> Now you can insert the pragma in those sourcefiles that are new or
>> already fixed and you can immediately benefit from the feature and you
>> can upgrade your code file by file or even scope by scope.
>>
>> Later versions could even introduce #pragma(past, notuplesyntax) before
>> dropping the old syntax completely.
>>
>
> This scheme don't allow for breaking change to be made. It also require the compiler to handle a mess of features that can be activated or not. This is way more work, and I don't really see the benefice.
>
> As non breaking change are introduced in a different process than breaking one, it is easy to migrate to new version that will not break legacy code and provide new features.

OTOH, it may break the community yet again, which we certainly don't want, probably even less than breaking code.
Also, the example of Python with two main stable branches that live in parallel is not very encouraging.
July 15, 2012
> OTOH, it may break the community yet again, which we certainly
> don't want, probably even less than breaking code.
> Also, the example of Python with two main stable branches that
> live in parallel is not very encouraging.

Are you kidding? Python should be used as example of how software should be engineered. They keep release schedules, keep stable versions & never break backward compatibility without giving their users ways to not be stuck in bad situation. It is well thought and planned. Its popularity and widespread is not a coincidence,  and the fact that it became de facto part of linuxes (shipping with 5 year old versions without a fear of deprecation) just proves people can count on it and use it without fear of some random unguided development that is typical of D with its half thought our new features that bite it on the ass year later.
July 15, 2012
> OTOH, it may break the community yet again, which we certainly
> don't want, probably even less than breaking code.
> Also, the example of Python with two main stable branches that
> live in parallel is not very encouraging.

Also, check Python website: they recommend python v2 for all new users that don't know what to choose. They are both stable, but v2 has more libraries, and they do reassure them by saying v2 will be supported for time to come.

On the other hand, on D website, D1 is pushed to the dark corners as ugly half child nobody should know about, and D2 is titled as thing to chose without thinking. And there is no mentioning D1 is relatively stable, while D2 is still unstable, non conforming to D documentation and that some things just don't work, while in constant beta flux that breaks things on regular basis with each release.

So tell me again, which language treats its users with more respect ? Which one encourages users more to use them?
July 15, 2012
On Sunday, 15 July 2012 at 20:44:01 UTC, Patrick Stewart wrote:
>> OTOH, it may break the community yet again, which we certainly don't want, probably even less than breaking code.
>> Also, the example of Python with two main stable branches that live in parallel is not very encouraging.
>
> Are you kidding? Python should be used as example of how software should be engineered. They keep release schedules, keep stable versions & never break backward compatibility without giving their users ways to not be stuck in bad situation. It is well thought and planned. Its popularity and widespread is not a coincidence,  and the fact that it became de facto part of linuxes (shipping with 5 year old versions without a fear of deprecation) just proves people can count on it and use it without fear of some random unguided development that is typical of D with its half thought our new features that bite it on the ass year later.

I understand your gripe with breaking changes and bugs, but your painting of the sate of things is caricatural. First Linuxes are not shipping with 5 year old versions of Python, they usually ship with 2.7 which is the last version of the 2 branch. Meanwhile, the 3 branch is having a hard time getting used, several years after its introduction, and some major packages still haven't been ported.
http://wiki.python.org/moin/Python2orPython3
That is what I was referring to.

I agree the Python roadmap is better paved than the D roadmap, which hardly exists. It does make a case for a dev and a stable branch, which makes complete sense. OTOH, Python has suffered from disruptive changes just as much as D, like the fact that incorporating UTF in the language has justified a completely new branch. And talking about half assed features, its reference implementation suffers from *major* issues, like being slow (about 5 times slower than the Pypy JIT implementation) and monothreaded. And that is not going to be fixed any time soon. And you can't use PyPy for most serious web projects as native libraries are not compatible and haven't been ported.
July 15, 2012
On Sunday, 15 July 2012 at 20:50:47 UTC, Patrick Stewart wrote:
>> OTOH, it may break the community yet again, which we certainly don't want, probably even less than breaking code.
>> Also, the example of Python with two main stable branches that live in parallel is not very encouraging.
>
> Also, check Python website: they recommend python v2 for all new users that don't know what to choose. They are both stable, but v2 has more libraries, and they do reassure them by saying v2 will be supported for time to come.
>
> On the other hand, on D website, D1 is pushed to the dark corners as ugly half child nobody should know about, and D2 is titled as thing to chose without thinking. And there is no mentioning D1 is relatively stable, while D2 is still unstable, non conforming to D documentation and that some things just don't work, while in constant beta flux that breaks things on regular basis with each release.
>
> So tell me again, which language treats its users with more respect ? Which one encourages users more to use them?

The problem I raised is not a problem of respect. It's a problem of community. The D community is a tiny fraction of the Python community. It has been steadily growing this last year and a half or so, but it's still fragile. The D1/D2 split basically set it back to near zero for several years, with many people leaving, only a few staying, and a number recently coming back.

The project certainly can't afford yet another split, or many key people will simply throw the towel. I for one would rather see part of the users quitting than active members.

As for the stability of D2, upir opinion may be different, but it has largely improved recently due to increased forces, as several people have noted (David Simcha in a recent thread said something about the stability of the compiler being good enough that he only rarely encountered a problem). And considering the rate of bugs correction, it will continue to improve. You only need to have a look at the changelog to see that it's growing with each release, and I'm pretty confident that the 2.060 will contain more bug fixes than any past release.
July 15, 2012
On Sun, 15 Jul 2012 14:20:14 -0700, SomeDude <lovelydear@mailmetrash.com> wrote:

> On Sunday, 15 July 2012 at 20:44:01 UTC, Patrick Stewart wrote:
>>> OTOH, it may break the community yet again, which we certainly don't want, probably even less than breaking code.
>>> Also, the example of Python with two main stable branches that live in parallel is not very encouraging.
>>
>> Are you kidding? Python should be used as example of how software should be engineered. They keep release schedules, keep stable versions & never break backward compatibility without giving their users ways to not be stuck in bad situation. It is well thought and planned. Its popularity and widespread is not a coincidence,  and the fact that it became de facto part of linuxes (shipping with 5 year old versions without a fear of deprecation) just proves people can count on it and use it without fear of some random unguided development that is typical of D with its half thought our new features that bite it on the ass year later.
>
> I understand your gripe with breaking changes and bugs, but your painting of the sate of things is caricatural. First Linuxes are not shipping with 5 year old versions of Python, they usually ship with 2.7 which is the last version of the 2 branch. Meanwhile, the 3 branch is having a hard time getting used, several years after its introduction, and some major packages still haven't been ported.
> http://wiki.python.org/moin/Python2orPython3
> That is what I was referring to.
>
> I agree the Python roadmap is better paved than the D roadmap, which hardly exists. It does make a case for a dev and a stable branch, which makes complete sense. OTOH, Python has suffered from disruptive changes just as much as D, like the fact that incorporating UTF in the language has justified a completely new branch. And talking about half assed features, its reference implementation suffers from *major* issues, like being slow (about 5 times slower than the Pypy JIT implementation) and monothreaded. And that is not going to be fixed any time soon. And you can't use PyPy for most serious web projects as native libraries are not compatible and haven't been ported.

To be fair, the majority of the problems you listed with Python have nothing to do with their release process but their design process. The two are unrelated. The fact that it suffers disruptive changes is an argument for dev/stable branches, not against.

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/