On Tuesday, 27 November 2012 at 21:26:47 UTC, Walter Bright wrote:
> On 11/28/2012 8:23 AM, Walter Bright wrote:
>> It is unbelievably frustrating for people to have their code break with
>> each new release, have older projects all invalidated, with few willing
>> to do the maintenance work to bring them back on line.
>
>
> Note the thread next to this one: "Errors compiling DSSS", and the advice to abandon it.

It looks I am living in a parallel reality. In my world, DSSS has been abandoned for 4(!) years already! The author quit long before D2 feature-freeze was announced. There are a couple of forks but they do not seem to be maintained either. Why would anyone expect an unmaintained project like that to compile with new versions of an evolving language?

Most open source projects die. Students get jobs. That happens. Even the "stable" dmd1 is unlikely to compile any abandoned project at dsource. dsource itself is down more often than not. Should we keep them on life support?

On 11/28/12 2:38 AM, Jacob Carlborg wrote:
> On 2012-11-28 02:40, deadalnix wrote:
>
>> Don't you think that this whole situation is due to adding feature after
>> feature in an unstabilized mess ?
>
> It is, that's the major problem with D. Not the actual code breakage,
> rather how those are introduced.

I agree. We must drop this mom-and-pop-shop attitude like a bad habit.

Andrei

On 11/28/12 2:55 AM, Jacob Carlborg wrote:
> This is mostly a problem about how the project is run and managed. No
> road map, a poor release process, committing new features directly to
> the master branch. Unstable features added, added even before they're
> can be considered finished. I mean, "const" was one of the first things
> added to D2, it still has problems and druntime/Phobos is still not
> const correct.

Totally agreed. One issue now is that Walter has converged briskly on the simplistic conclusion "no more steenking breakages" instead of learning git and designing a useful process around it. That way the process remains broken instead of being identified as the main issue and fixed. I have advocated privately in much stronger terms than I could afford publicly that we must fix the process and exercise good judgment about changing the language - all to no avail. "No more breakages" is like taking an aspirin for the fever caused by gangrene.

I think with dread about what's coming when completing shared will be on the table. We'll be looking at not breaking code that was by definition broken.


Andrei

On 11/28/12 4:26 AM, Jacob Carlborg wrote:
> On 2012-11-27 22:23, Walter Bright wrote:
>
>> I understand what you're saying, but the counterpoint is we lost half
>> the D community when D2 broke D1 code. We still have at least one major
>> D1 user that still finds it impractical to upgrade to D2.
>>
>> It is unbelievably frustrating for people to have their code break with
>> each new release, have older projects all invalidated, with few willing
>> to do the maintenance work to bring them back on line.
>
> In the keynote for the latest Ruby on Rails conference. The original
> creator of Ruby on Rails goes out and say: Yes, Rails 4 will break
> existing code. He also says that progress is good and one should keep a
> young mind.
>
> I can assure you that Ruby on Rails has vastly more commercial
> developers than D has.
>
> What I mean is that that process of improving the language most not stop
> and should always continue. It's just the process how that is made that
> makes the big difference.

Yep. Rails 4 breaks Rails 3 code. Not Rails 3.061 breaks Rails 3.060 code :o).

Andrei

On 2012-11-28 13:43, Andrei Alexandrescu wrote:

> Totally agreed. One issue now is that Walter has converged briskly on
> the simplistic conclusion "no more steenking breakages" instead of
> learning git and designing a useful process around it. That way the
> process remains broken instead of being identified as the main issue and
> fixed. I have advocated privately in much stronger terms than I could
> afford publicly that we must fix the process and exercise good judgment
> about changing the language - all to no avail. "No more breakages" is
> like taking an aspirin for the fever caused by gangrene.
>
> I think with dread about what's coming when completing shared will be on
> the table. We'll be looking at not breaking code that was by definition
> broken.

Thanks again for acknowledging these problems. I do really hope what we can see some changes in this area.

-- 
/Jacob Carlborg

On 2012-11-28 13:46, Andrei Alexandrescu wrote:

> Yep. Rails 4 breaks Rails 3 code. Not Rails 3.061 breaks Rails 3.060
> code :o).

I've talked about that before. D doesn't have a versioning scheme that makes any sense. It's just a number that gets incremented without any meaning. Except that a greater number indicates a later version. Also changes to the language, compiler, runtime and standard library always happen in the same release.

-- 
/Jacob Carlborg

On 11/28/2012 07:31 AM, Jacob Carlborg wrote:
> On 2012-11-28 13:46, Andrei Alexandrescu wrote:
>
>> Yep. Rails 4 breaks Rails 3 code. Not Rails 3.061 breaks Rails 3.060
>> code :o).
>
> I've talked about that before. D doesn't have a versioning scheme that
> makes any sense. It's just a number that gets incremented without any
> meaning. Except that a greater number indicates a later version. Also
> changes to the language, compiler, runtime and standard library always
> happen in the same release.
>

I must admit that I'm surprised that no one has simply forked the project in order to apply their own versioning scheme to it.

On Wednesday, 28 November 2012 at 13:31:36 UTC, Jacob Carlborg wrote:
> On 2012-11-28 13:46, Andrei Alexandrescu wrote:
>
>> Yep. Rails 4 breaks Rails 3 code. Not Rails 3.061 breaks Rails 3.060
>> code :o).
>
> I've talked about that before. D doesn't have a versioning scheme that makes any sense. It's just a number that gets incremented without any meaning. Except that a greater number indicates a later version. Also changes to the language, compiler, runtime and standard library always happen in the same release.

When people refer to D1, D2, D3, and eventually D4, etc, what they should be referring to is a major version upgrade that will purposefully contain breaking changes, and will inevitably introduce a whole new set of bugs.

Usually increments to a minor version mean increasing stability, not decreasing stability or unknown stability!

Major version increments means that breaking changes may be introduced on purpose for a good reason, and it may mean new bugs will be introduced as well.

The major/minor versioning system has been in use for ages. Many people rely on it, including myself. I use different packages, that I purposely keep at a certain major revision number, and I always happily update to the next minor version, because it introduces bug fixes, not breaking changes. I only migrate to the next major revision only after it has matured over a few minor increments.

Again, sometimes I jump on the next breaking major revision, because it's for non-critical work, or for a new feature that I really need today. The point is that I can identify what is breaking and what is not just by looking at the version number, and I can pick and choose which version I think fits the stability model for my situation.

In any case, I did suggest re-thinking how a language can be made to change in significant ways over time. The major.minor version concept may be too simplistic for this, but holy crap, it's at least a good start since we don't even have that!

Something has to change, and it has to change quickly.

--rt

On Wednesday, 28 November 2012 at 17:19:48 UTC, 1100110 wrote:
> On 11/28/2012 07:31 AM, Jacob Carlborg wrote:
>> On 2012-11-28 13:46, Andrei Alexandrescu wrote:
>>
>>> Yep. Rails 4 breaks Rails 3 code. Not Rails 3.061 breaks Rails 3.060
>>> code :o).
>>
>> I've talked about that before. D doesn't have a versioning scheme that
>> makes any sense. It's just a number that gets incremented without any
>> meaning. Except that a greater number indicates a later version. Also
>> changes to the language, compiler, runtime and standard library always
>> happen in the same release.
>>
>
> I must admit that I'm surprised that no one has simply forked the project in order to apply their own versioning scheme to it.

Well, D has been forked in the past (tango vs phobos) but it tended to make things even worse.

On 11/28/2012 11:49 AM, deadalnix wrote:
> On Wednesday, 28 November 2012 at 17:19:48 UTC, 1100110 wrote:
>> On 11/28/2012 07:31 AM, Jacob Carlborg wrote:
>>> On 2012-11-28 13:46, Andrei Alexandrescu wrote:
>>>
>>>> Yep. Rails 4 breaks Rails 3 code. Not Rails 3.061 breaks Rails 3.060
>>>> code :o).
>>>
>>> I've talked about that before. D doesn't have a versioning scheme that
>>> makes any sense. It's just a number that gets incremented without any
>>> meaning. Except that a greater number indicates a later version. Also
>>> changes to the language, compiler, runtime and standard library always
>>> happen in the same release.
>>>
>>
>> I must admit that I'm surprised that no one has simply forked the
>> project in order to apply their own versioning scheme to it.
>
> Well, D has been forked in the past (tango vs phobos) but it tended to
> make things even worse.

Well I was thinking more along the lines of prevent breaking changes but I suppose you are right.

And now that you mention it, I suppose I've forked the GC as well...