On Saturday, November 29, 2014 10:46:14 Daniel Murphy via Digitalmars-d wrote:
> Two years is too old, you skipped all the deprecation stages.

That's pretty much the long and short of it. The deprecation cycle for stuff in druntime/Phobos is currently about two years long (one year as deprecated and documented, one year as deprecated and undocumented). So, anything that had been in the deprecation cycle when Walter last touched that code would be long out of it by now, and depending on when the releases really fell vs how close to two years it's really been, it wouldn't be that hard for some stuff to have started and completed the deprecation cycle since the last time he updated that code. We haven't even been trying to make it so that code can be unmaintained for two years and then still build with no changes. It's pretty much been the expectation that anything untouched for that long is essentially dead. We don't deprecate anywhere near as much stuff as we used to or do it anywhere near as frequently, but two years is long enough that you're going to skip the entire deprecation cycle for stuff.

We can certainly look at increasing the length of time for the deprecation process, but that creates more cruft in the library, increases the risk of symbol conflicts and makes for more code to maintain - code that shouldn't even be used anymore. The primary solution has been simply to raise the bar for what changes we'll accept that will result in deprecations. But they still happen sometimes if the change is deemed worthwhile enough (in particular, it sounds like Walter's big problem is that std.path was redone a while back, which was definitely more than simply renaming stuff). And the only way to outright prevent code breaking due to changes like this, we'd have to keep deprecated stuff around indefinitely, which is a maintenance problem.

I'm not completely against increasing the length of the deprecation cycle in order to reduce the risk of code breaking without notice when it's not actively maintained (e.g. from two years to three), but I also don't think that it's completely reasonable to expect that code which is untouched for two years will work with the latest compiler and library. Not even the language itself is that stable, and it's a _lot_ more stable than it used to be. I completely agree that we should be trying to reduce code breakage even over longer periods of time (and I think that we definitely _have_ reduced it, even if it's not by enough to allow Walter to compile his two year old microemacs code without using any compilers in between), but I also think that the expectation that old code should compile several years later with no changes and without using any compilers in between is higher than reasonable. I'm not sure that that even works with C++ compilers, much as it should - especially when you go from C++98 to C++11 or C++14, and since D is continually in flux (even if it's a lot less flux than it used to be), doing something like going from 2.058 to 2.066 is a lot like going from C++98 to C++11. To really have full stability, we'd pretty much have to freeze everything and change nothing beyond bug fixes, and we're definitely not doing that. Heck, simply introducing a new function to Phobos can break existing code, because it can create a symbol conflict. It's an easy fix, but stuff like that makes it nigh on impossible to guarantee that we won't break two-year old code.

- Jonathan M Davis

On Friday, 28 November 2014 at 23:33:54 UTC, Walter Bright wrote:
> Just for fun, I've decided to try and get MicroEmacs in D added to the dub registry. The last time it compiled was 2 years ago.
>
> I wound up with at least a dozen references to Phobos names that have disappeared. No corrective action was indicated, just "undefined symbol". I have to go refigure out what the code was trying to do, and go poking through the Phobos documentation to see what will work today.
>
> I know there's been a lot of "break my code" advocacy lately, but this code was only 2 years old.
>
> I fully understand how unfriendly this is to users and how discouraging it can be to have their recently working code shattered and scattered. We need to do a lot better.

I've just made xmlp (http://www.dsource.org/projects/xmlp) compile with the newest version of D. It wasn't that bad, despite xmlp rotting for two years with merge markers left in it. However what would have made this even easier, would be

a) a summary for each release called "How this version breaks your code and how to fix it". Don't need that for library changes, language changes are enough.

b) easy access to older versions of the documentation. When you have a deprecated and subsequently removed function, you should at least be able to lookup what the code was supposed to do.

You probably have realized that the obvious solution to breakage is:

1. To have two branches: stable and experimental

2. Backport serious bugfixes to stable, but not "bug is a feature" bugs.

3. Provide an upgrade tool when a new stable branch is created (meaning: a new stable branch is not created until the source-code upgrade tool is ready)

4. Create a planned release scheduled for stable branch (say 18-24 months)

On Sun, Nov 30, 2014 at 03:03:23AM -0800, Jonathan M Davis via Digitalmars-d wrote: [...]
> be. I completely agree that we should be trying to reduce code breakage even over longer periods of time (and I think that we definitely _have_ reduced it, even if it's not by enough to allow Walter to compile his two year old microemacs code without using any compilers in between), but I also think that the expectation that old code should compile several years later with no changes and without using any compilers in between is higher than reasonable. I'm not sure that that even works with C++ compilers, much as it should - especially when you go from C++98 to C++11 or C++14, and since D is continually in flux (even if it's a lot less flux than it used to be), doing something like going from 2.058 to 2.066 is a lot like going from C++98 to C++11.

FWIW, I have C++ code dating from 10 years ago that still compiles with C++11. Granted, I needed to fix a thing or two here and there, but they were pretty straightforward (compiler warnings / errors told you exactly why the code doesn't work anymore). But then again, it's not like C++11 replaced an entire standard library module in the process -- they did introduce new and better modules but old ones were kept around.


> To really have full stability, we'd pretty much have to freeze everything and change nothing beyond bug fixes, and we're definitely not doing that. Heck, simply introducing a new function to Phobos can break existing code, because it can create a symbol conflict.

Speaking of which, this problem is made a lot worse than it could be, because currently private symbols in imported modules are included in the overload set, so introducing a *private* symbol can break unrelated user code downstream. Ugh.


> It's an easy fix, but stuff like that makes it nigh on impossible to guarantee that we won't break two-year old code.
[...]

I think the complaint was not so much the fact that the code broke, but the fact that it broke *without any clue as to how to fix it*. Now, if we had something like @disable with an optional message, we could do something like:

	@disabled("Please use globMatch instead") auto fnmatch(...);

At least in theory, this would fix the problem. Of course, in practice, things rarely work out so nicely except in retrospect. :-P


T

-- 
MAS = Mana Ada Sistem?

On Sun, Nov 30, 2014 at 12:55:34PM +0000, via Digitalmars-d wrote:
> You probably have realized that the obvious solution to breakage is:
> 
> 1. To have two branches: stable and experimental
> 
> 2. Backport serious bugfixes to stable, but not "bug is a feature" bugs.
> 
> 3. Provide an upgrade tool when a new stable branch is created (meaning: a new stable branch is not created until the source-code upgrade tool is ready)
> 
> 4. Create a planned release scheduled for stable branch (say 18-24
> months)

This wouldn't help Walter's original problem. He was taking code written from >=2 years ago and compiling it with the latest compiler.


T

-- 
"A man's wife has more power over him than the state has." -- Ralph Emerson

On Sun, Nov 30, 2014 at 12:15:48PM +0000, Tobias Pankrath via Digitalmars-d wrote: [...]
> I've just made xmlp (http://www.dsource.org/projects/xmlp) compile with the newest version of D. It wasn't that bad, despite xmlp rotting for two years with merge markers left in it. However what would have made this even easier, would be
> 
> a) a summary for each release called "How this version breaks your code and how to fix it". Don't need that for library changes, language changes are enough.

I thought dlang.org already has a page that lists language & library changes for each of the recent releases? Those lists tend to be pretty long, though, which means people aren't likely to actually read it all. I wonder if there are other ways of navigating them so that they are actaully useful.


> b) easy access to older versions of the documentation. When you have a deprecated and subsequently removed function, you should at least be able to lookup what the code was supposed to do.
[...]

Good idea! We should archive docs from older versions of Phobos and make them accessible on dlang.org. I'm working on revamping some parts of the Phobos docs build; once that's in, it might not be too hard to make it also generate docs for older releases.


T

-- 
What do you call optometrist jokes? Vitreous humor.

On Sunday, 30 November 2014 at 15:32:31 UTC, H. S. Teoh via Digitalmars-d wrote:
> This wouldn't help Walter's original problem. He was taking code written
> from >=2 years ago and compiling it with the latest compiler.

I assumed he meant to make a forward looking statement, i.e. how to deal with this from now on.

In two years Walter would run the upgradetool spanning 1-2 releases, and get the automatic fixes and the warnings where manual intervention is needed.

On 11/30/2014 7:36 AM, H. S. Teoh via Digitalmars-d wrote:
> Good idea! We should archive docs from older versions of Phobos and make
> them accessible on dlang.org. I'm working on revamping some parts of the
> Phobos docs build; once that's in, it might not be too hard to make it
> also generate docs for older releases.

I decided to try and update DMDScript from D1 to D2. Thousands and thousands of error messages :-(

30-Nov-2014 23:22, Walter Bright пишет:
> On 11/30/2014 7:36 AM, H. S. Teoh via Digitalmars-d wrote:
>> Good idea! We should archive docs from older versions of Phobos and make
>> them accessible on dlang.org. I'm working on revamping some parts of the
>> Phobos docs build; once that's in, it might not be too hard to make it
>> also generate docs for older releases.
>
> I decided to try and update DMDScript from D1 to D2. Thousands and
> thousands of error messages :-(
>

Even back in 2010 it took about 10 evenings to get it to "runnable" state. Then another ~20 evenings to fix most of bugs, including semantic errors and GC collecting live objects.

You may want to check my fork that used to compile with dmd 2.058 or smth (whatever was actual in 2012). Might help to assess the amount of work...
https://github.com/DmitryOlshansky/DMDScript

It at least passed about 90% (most fails in library tests) of 2012 Google's Spuntik JavaScript test.

-- 
Dmitry Olshansky

Walter Bright:

> I decided to try and update DMDScript from D1 to D2. Thousands and thousands of error messages :-(

It's not just the errors, it's also the new features and opportunities offered by the newer D/Phobos that you weren't using in the old code... Just removing the errors is usually not enough to produce modern and very good D2 code.

Bye,
bearophile