www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Breaking D2 language/spec changes with D1 being discontinued in a

reply "SiegeLord" <none none.com> writes:
Another DMD alpha, another set of previously valid code that no 
longer compiles. With 2.060 it was the TypeInfo constness changes 
in druntime, with 2.061 it is the dissalowance of rebindability 
of the this pointer. The latter did make it into the spec half a 
year ago, but recently it was actually dissallowed in the beta. 
Unlike many other features of the sort (e.g. octal literals) 
there is no warning or deprecation errors... code that use to 
compile simply does not anymore.

In this last case, in principle, we were lucky... the spec was 
changed. What about things like this: 
http://dlang.org/attribute.html#inout . Are those undocumented 
features liable to change at any time? What warning will there be 
when somebody decides to submit an inout bug and somebody else 
fixes it in a way that breaks existing code?

D1 is scheduled to be discontinued in a month, and every new 
version of DMD keeps changing D2 in code breaking ways (or worse, 
with backwards incompatible spec changes). I think that unless 
people responsible for these things get their act together and 
stabilize D2 against these issues, D1 support should be extended 
until that happens.
Nov 27 2012
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
SiegeLord:

 I think that unless people responsible for these things get 
 their act together and stabilize D2 against these issues, D1 
 support should be extended until that happens.
It will take some more years to see D2 "stabilized" like that. The decision to discontinue D1 has some disadvantages, but keeping D1 updated uses some work time that could be (better) spent improving D2. Bye, bearophile
Nov 27 2012
next sibling parent reply "SiegeLord" <none none.com> writes:
On Wednesday, 28 November 2012 at 02:29:12 UTC, bearophile wrote:

 It will take some more years to see D2 "stabilized" like that. 
 The decision to discontinue D1 has some disadvantages, but 
 keeping D1 updated uses some work time that could be (better) 
 spent improving D2.
With that kind of attitude D2 will never stabilize. I remember two years ago I was told that once TDPL was published, the language would become stable. Two years later everything is just as in flux as it was back then. The welcome fixation of bugs is befouled with deliberate code breakage left and right. There is absolutely no guarantee of backwards compatibility between DMD versions. This situation is simply unheard of. Vast majority of respectable software inititives provide a stable version that guarantees source and possibly binary compatibility, and an unstable version that does not. They use versioning schemes where a match of some part of the version number assures compatibility. Is there absolutely no concern for D users's code? It certainly seems like it. Maybe it would have made sense a decade ago when D was just starting... but D has been around for over 11 years now. To have screwed up so badly that after 11 years you still don't have a stable platform to write code for (well, you do with D1, but in a month there will not be that excuse) is mind boggling.
Nov 27 2012
next sibling parent reply Robert <jfanatiker gmx.at> writes:
 Is there absolutely no concern for D users's code? It certainly 
 seems like it. Maybe it would have made sense a decade ago when D 
 was just starting... but D has been around for over 11 years now. 
 To have screwed up so badly that after 11 years you still don't 
 have a stable platform to write code for (well, you do with D1, 
 but in a month there will not be that excuse) is mind boggling.
I tend to disagree a bit. First D is a very, very powerful language written by just a few people, with no commercial background, so I think it is quite reasonable that it takes more time to stabilize than much simpler languages, let's say python. I also in general think, that fixing things is a good idea, even if breaking code, but it is really annoying if your code breaks, especially if you can not easily find the reason. For this reason and others (more testing) I would also very much appreciate (I already suggested this before) to have a stable branch, that really only receives bug fixes and a new major version release every half a year or so (given D's speed of development). It should not be too frequent, because it will be a lot of work: 1. Document precisely any breaking changes for the new version + a recommend way of updating (which was tested). 2. Provide tools that fix your code automatically. Wherever reasonable & possible. Because I think, the least you can do is to have a thorough discussion somewhere of what breaks and how to fix it. I would be very much less pissed by breaking changes, if I could at least look them up quickly and get a solution for it. For point 2, we would start with some easy tools like search and replace (for name changes and such) and improve them over time to parse context, ... (e.g. like http://coccinelle.lip6.fr/sp.php ) -> The easier and automated the upgrade path, the better. Old version could be supported until the major version after the next one comes out. Encourage people to upgrade early and make it as easy as possible for them. Are breaking changes of any kind documented somewhere at the moment? The release model I have in mind: 1. Every few months a new minor release for both the unstable and the stable version. (To get early and good testing for the unstable version & to find out any unexpected breakings) 2. Every six/eight/twelve months: The current unstable will become the new stable with all breakings perfectly documented & uprade scripts written. If it is too much work to support two stable versions, we could drop updates as soon as a new version comes out. Breaking changes should still be avoided of course, but if needed they should be possible. Best regards, Robert
Nov 27 2012
parent "deadalnix" <deadalnix gmail.com> writes:
On Wednesday, 28 November 2012 at 07:52:54 UTC, Robert wrote:
 Is there absolutely no concern for D users's code? It 
 certainly seems like it. Maybe it would have made sense a 
 decade ago when D was just starting... but D has been around 
 for over 11 years now. To have screwed up so badly that after 
 11 years you still don't have a stable platform to write code 
 for (well, you do with D1, but in a month there will not be 
 that excuse) is mind boggling.
I tend to disagree a bit. First D is a very, very powerful language written by just a few people, with no commercial background, so I think it is quite reasonable that it takes more time to stabilize than much simpler languages, let's say python.
Actually, this is true that D have little resources, and the work done is really incredible. To be fair, D community is one of the most technically competent I know of. That being said, the problem isn't the amount of work, but how it is managed. Thinking that D is not stable because of resource is just avoiding to look at the truth.
Nov 28 2012
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-11-28 08:17, SiegeLord wrote:

 With that kind of attitude D2 will never stabilize.

 I remember two years ago I was told that once TDPL was published, the
 language would become stable. Two years later everything is just as in
 flux as it was back then.
TDPL was release way, way too soon. It was written before many of the features were even implemented. Then at a later stage "Whoops, this apparently doesn't work, we need to break TDPL". The welcome fixation of bugs is befouled with
 deliberate code breakage left and right. There is absolutely no
 guarantee of backwards compatibility between DMD versions. This
 situation is simply unheard of. Vast majority of respectable software
 inititives provide a stable version that guarantees source and possibly
 binary compatibility, and an unstable version that does not. They use
 versioning schemes where a match of some part of the version number
 assures compatibility.
I think all this is mostly a project management issue. I don't think the breaking changes in them self is the biggest problem. See my post in another thread: http://forum.dlang.org/thread/mailman.2250.1353947827.5162.digitalmars-d puremagic.com?page=5#post-k94g19:2427kh:241:40digitalmars.com -- /Jacob Carlborg
Nov 28 2012
next sibling parent reply "SiegeLord" <none none.com> writes:
On Wednesday, 28 November 2012 at 08:01:02 UTC, Jacob Carlborg 
wrote:

 I think all this is mostly a project management issue. I don't 
 think the breaking changes in them self is the biggest problem.
After years of using D1 and D2, I've lowered my expectations about what can be changed for the better with D as long as the current captains are at the helm. You can change the language, but you can't change the person. Yes, ultimately if the project was managed better the code breaking issue would be mitigated for free, but that's not happening. Bad management is one of the invariants of D's history. Given that invariant, I just want a tiny concession... I want my code not to break with every new version of DMD. If some breaking change must be introduced, I want ample warning, preferrably in the form of a compillation warning or a deprecation message, so I don't have to scamper to fix my code in a few weeks/days after each DMD release, but have the leisure to do it over a release cycle. A quick aside about D1... it in fact has amazing stability. I recently compiled Kenta Cho's D games which were written before D 1.0... I only had to make a few changes here and there for it to compile with the most recent DMD1. Far less than the amount of changes I had to make when upgrading from 2.059 to 2.060 with the D2 codebase I maintain (Tango D2 and my personal projects). With D1 being discontinued, it is clear where the priorities lie... definitely not on stability of people's code. And before people come and say that they have thousands of D2 commercial code that they don't mind breaking every release... let me suggest that perhaps for every 1 of you, there are 99 others who don't care for such nonsense?
Nov 28 2012
next sibling parent reply "Max Samukha" <maxsamukha gmail.com> writes:
On Wednesday, 28 November 2012 at 08:40:32 UTC, SiegeLord wrote:
 On Wednesday, 28 November 2012 at 08:01:02 UTC, Jacob Carlborg 
 wrote:

 I think all this is mostly a project management issue. I don't 
 think the breaking changes in them self is the biggest problem.
After years of using D1 and D2, I've lowered my expectations about what can be changed for the better with D as long as the current captains are at the helm. You can change the language, but you can't change the person. Yes, ultimately if the project was managed better the code breaking issue would be mitigated for free, but that's not happening. Bad management is one of the invariants of D's history. Given that invariant, I just want a tiny concession... I want my code not to break with every new version of DMD. If some breaking change must be introduced, I want ample warning, preferrably in the form of a compillation warning or a deprecation message, so I don't have to scamper to fix my code in a few weeks/days after each DMD release, but have the leisure to do it over a release cycle. A quick aside about D1... it in fact has amazing stability. I recently compiled Kenta Cho's D games which were written before D 1.0... I only had to make a few changes here and there for it to compile with the most recent DMD1. Far less than the amount of changes I had to make when upgrading from 2.059 to 2.060 with the D2 codebase I maintain (Tango D2 and my personal projects). With D1 being discontinued, it is clear where the priorities lie... definitely not on stability of people's code.
I have a different concession. I come here on a regular basis to see if the issues hampering some long-overdue work that is important to me (and arguably to the community) have been resolved. There has been great progress thanks to Kenji Hara, Don and others but a couple of critical issues still remain (like this one http://d.puremagic.com/issues/show_bug.cgi?id=5380). I don't give a darn whether fixing the language and tools breaks other people's code. It is *their* code that is wrong and should be changed. We should not need to clutter ours with the ugliest of workarounds because people didn't care to think about what they were doing. If they can't or don't want to do the right thing, let them stick to the buggy compiler builds that work for them.
 And before people come and say that they have thousands of D2 
 commercial code that they don't mind breaking every release... 
 let me suggest that perhaps for every 1 of you, there are 99 
 others who don't care for such nonsense?
Nov 28 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/28/2012 11:34 P I come here on a regular basis to see if
 the issues hampering soM, Max Samukha wrote:
 I have a different concession.me long-overdue work that is important to me (and
 arguably to the community) have been resolved. There has been great
 progress thanks to Kenji Hara, Don and others but a couple of critical
 issues still remain (like this one
 http://d.puremagic.com/issues/show_bug.cgi?id=5380).
That issue is marked as "normal", not critical. You can raise it to critical, but if you do, please add an explanation why. Ditto for any others you find critical.
Nov 28 2012
parent reply "Max Samukha" <maxsamukha gmail.com> writes:
On Wednesday, 28 November 2012 at 12:53:34 UTC, Walter Bright 
wrote:
 On 11/28/2012 11:34 P I come here on a regular basis to see if
 the issues hampering soM, Max Samukha wrote:
 I have a different concession.me long-overdue work that is 
 important to me (and
 arguably to the community) have been resolved. There has been 
 great
 progress thanks to Kenji Hara, Don and others but a couple of 
 critical
 issues still remain (like this one
 http://d.puremagic.com/issues/show_bug.cgi?id=5380).
That issue is marked as "normal", not critical. You can raise it to critical, but if you do, please add an explanation why. Ditto for any others you find critical.
From my and other people's experience, setting bug severity, voting for bugs etc. usually has no effect, so I stopped doing that long ago. Raised the severity and added a rationale.
Nov 28 2012
parent Walter Bright <newshound2 digitalmars.com> writes:
On 11/29/2012 2:18 AM, Max Samukha wrote:
  From my and other people's experience, setting bug severity, voting for
 bugs etc. usually has no effect, so I stopped doing that long ago.

 Raised the severity and added a rationale.
Thank you.
Nov 28 2012
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/28/2012 7:40 PM, SiegeLord wrote:
 A quick aside about D1... it in fact has amazing stability. I recently
 compiled Kenta Cho's D games which were written before D 1.0... I only
 had to make a few changes here and there for it to compile with the most
 recent DMD1. Far less than the amount of changes I had to make when
 upgrading from 2.059 to 2.060 with the D2 codebase I maintain (Tango D2
 and my personal projects). With D1 being discontinued, it is clear where
 the priorities lie... definitely not on stability of people's code.
On the other hand, many people were unhappy with my position of "no breaking changes at all outside of clear bug fixes" to D1, which also implied "no language enhancements". There were many enhancements to the code generation, new platforms, etc., and many CTFE improvements (which I more or less regarded as bug fixing). There were also no changes allowed that affected binary compatibility. D1 isn't going away - it isn't going to be removed from the servers, etc. It's just not going to be officially supported anymore.
Nov 28 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-11-28 13:41, Walter Bright wrote:

 On the other hand, many people were unhappy with my position of "no
 breaking changes at all outside of clear bug fixes" to D1, which also
 implied "no language enhancements". There were many enhancements to the
 code generation, new platforms, etc., and many CTFE improvements (which
 I more or less regarded as bug fixing). There were also no changes
 allowed that affected binary compatibility.
Please, please try and understand. It's not breaking changes in it self that is the problem. It's how they're handled. Many people has also talked about something in between D1 and D2, D1.5 or similar. Which would contain bug fixes and new backwards compilable changes. -- /Jacob Carlborg
Nov 28 2012
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/29/2012 12:15 AM, Jacob Carlborg wrote:
 Many people has also talked about something in between D1 and D2, D1.5
 or similar. Which would contain bug fixes and new backwards compilable
 changes.
The trouble with that is now I'd be maintaining 3 versions of the compiler rather than two. Here's what happens nearly all the time. People create a pull request for a fix to D2. I don't just pull it, I review it and see if it is a fix that should be propagated to D1. If it is, I have to manually merge it into D1 (as the sources have substantially diverged by now). This gets fairly time consuming. Check the D1 commits labeled along the lines of "merge D2 pull #nnnn". Only a relatively small handful of times has anyone submitted a corresponding pull request for D1. Adding a 3rd compiler to do this to is a large time sink. I can see creating a stable D2 and a forward D2 for 6 months at a time or so, as has been proposed here. I think that's a good idea. But only after D1 is no longer supported.
Nov 28 2012
next sibling parent reply "Maxim Fomin" <maxim maxim-fomin.ru> writes:
On Wednesday, 28 November 2012 at 13:36:01 UTC, Walter Bright 
wrote:
 On 11/29/2012 12:15 AM, Jacob Carlborg wrote:
 Many people has also talked about something in between D1 and 
 D2, D1.5
 or similar. Which would contain bug fixes and new backwards 
 compilable
 changes.
The trouble with that is now I'd be maintaining 3 versions of the compiler rather than two. Here's what happens nearly all the time. People create a pull request for a fix to D2. I don't just pull it, I review it and see if it is a fix that should be propagated to D1. If it is, I have to manually merge it into D1 (as the sources have substantially diverged by now). This gets fairly time consuming. Check the D1 commits labeled along the lines of "merge D2 pull #nnnn". Only a relatively small handful of times has anyone submitted a corresponding pull request for D1. Adding a 3rd compiler to do this to is a large time sink. I can see creating a stable D2 and a forward D2 for 6 months at a time or so, as has been proposed here. I think that's a good idea. But only after D1 is no longer supported.
Thanks for writing this: it explains something regarding slowness of pull merging. Have you thought about adjusting D development model to D growth? Perhaps allowing permissive test branch or delegating parts of project to maintainers (like with linux)? Regarding breaking changes vs. keeping cripple features - it is a trade-off and certainly somebody will be in a loss position. Probably there is need to set up a clear policy - currently there are only talks and guesses about each problematic feature.
Nov 28 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/29/2012 12:56 AM, Maxim Fomin wrote:
 Have you thought about adjusting D development model to D growth?
 Perhaps allowing permissive test branch or delegating parts of project
 to maintainers (like with linux)?
Since D is a volunteer organization, my assigning tasks to people tends to not work. What does work is when a champion steps forward to take charge of some aspect. For example, Brad stepped forward to take over bugzilla and the D continuous testing, Vladimir stepped forward to do the D forums, Don stepped forward to champion CTFE, Andrei with Phobos, Sean with Druntime, etc. I am more than happy to delegate to a champion, and D would be nowhere near where it is today without the numerous champions we have that have all pretty much self-selected themselves.
 Regarding breaking changes vs. keeping cripple features - it is a
 trade-off and certainly somebody will be in a loss position. Probably
 there is need to set up a clear policy - currently there are only talks
 and guesses about each problematic feature.
There's no clear line between fixing a bug and adding a breaking change. In the end, it's a judgement call. If someone wants to be the champion of a stable D2 version branch, that would be great. His job would be to regularly review changes to D2, merge in the ones that make sense for the stable branch, make sure it gets through its test suite, and prepare releases of it now and then.
Nov 28 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-11-28 23:26, Walter Bright wrote:

 If someone wants to be the champion of a stable D2 version branch, that
 would be great. His job would be to regularly review changes to D2,
 merge in the ones that make sense for the stable branch, make sure it
 gets through its test suite, and prepare releases of it now and then.
You also need to promise that you will put up the releases at dlang.org and pointing users to the stable release first and foremost. -- /Jacob Carlborg
Nov 28 2012
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-11-28 14:35, Walter Bright wrote:

 The trouble with that is now I'd be maintaining 3 versions of the
 compiler rather than two.
I don't know if there would be a point of having D1 if something like D1.5 existed. It would still be as backwards compatible as D1 currently is.
 Here's what happens nearly all the time. People create a pull request
 for a fix to D2. I don't just pull it, I review it and see if it is a
 fix that should be propagated to D1. If it is, I have to manually merge
 it into D1 (as the sources have substantially diverged by now). This
 gets fairly time consuming. Check the D1 commits labeled along the lines
 of "merge D2 pull #nnnn".

 Only a relatively small handful of times has anyone submitted a
 corresponding pull request for D1.

 Adding a 3rd compiler to do this to is a large time sink.
I understand that. It's not feasible for one man to maintain three compilers. You need to be able to delegate to other people. That is regardless if there were a third compiler or not. See Maxim's answer to your post.
 I can see creating a stable D2 and a forward D2 for 6 months at a time
 or so, as has been proposed here. I think that's a good idea. But only
 after D1 is no longer supported.
Since D1 will be discontinued at the end of this year, if nothing has changed. It might be a good idea to start to plan for creating a stable D2. -- /Jacob Carlborg
Nov 28 2012
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/28/12 8:35 AM, Walter Bright wrote:
 On 11/29/2012 12:15 AM, Jacob Carlborg wrote:
 Many people has also talked about something in between D1 and D2, D1.5
 or similar. Which would contain bug fixes and new backwards compilable
 changes.
The trouble with that is now I'd be maintaining 3 versions of the compiler rather than two. Here's what happens nearly all the time. People create a pull request for a fix to D2. I don't just pull it, I review it and see if it is a fix that should be propagated to D1. If it is, I have to manually merge it into D1 (as the sources have substantially diverged by now). This gets fairly time consuming. Check the D1 commits labeled along the lines of "merge D2 pull #nnnn". Only a relatively small handful of times has anyone submitted a corresponding pull request for D1. Adding a 3rd compiler to do this to is a large time sink. I can see creating a stable D2 and a forward D2 for 6 months at a time or so, as has been proposed here. I think that's a good idea. But only after D1 is no longer supported.
The problem with the above is the count of "I", which is too large. We need to switch from "I" to "we" so we can scale up. Andrei
Nov 28 2012
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Wednesday, November 28, 2012 09:33:13 Andrei Alexandrescu wrote:
 The problem with the above is the count of "I", which is too large. We
 need to switch from "I" to "we" so we can scale up.
And opening up dmd to more committers was a good start, but the overall development process needs to go that way as well (as the situation with user- defined attributes helps illustrate). - Jonathan M Davis
Nov 28 2012
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/28/12 11:32 AM, Jonathan M Davis wrote:
 On Wednesday, November 28, 2012 09:33:13 Andrei Alexandrescu wrote:
 The problem with the above is the count of "I", which is too large. We
 need to switch from "I" to "we" so we can scale up.
And opening up dmd to more committers was a good start, but the overall development process needs to go that way as well (as the situation with user- defined attributes helps illustrate). - Jonathan M Davis
One good step toward that would be a combination of (a) a good wiki page and (b) a good set of git macros - that implements a simple and effective github-based process. Andrei
Nov 28 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-11-28 17:35, Andrei Alexandrescu wrote:

 One good step toward that would be a combination of (a) a good wiki page
 and (b) a good set of git macros - that implements a simple and
 effective github-based process.
git macros are only good if you know what you're doing. If you don't and something with the macros break, you're lost. BTw, git is not hard to learn. -- /Jacob Carlborg
Nov 28 2012
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 11/29/2012 1:33 AM, Andrei Alexandrescu wrote:
 The problem with the above is the count of "I", which is too large. We
 need to switch from "I" to "we" so we can scale up.
I understand this, see my other reply here about champions.
Nov 28 2012
prev sibling next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Walter Bright:

 I can see creating a stable D2 and a forward D2 for 6 months at 
 a time or so, as has been proposed here. I think that's a good 
 idea. But only after D1 is no longer supported.
I am OK with such ideas. Below there are some musings. How do you want to call (release numbers) those two D2 versions (Stable-D and Development-D)? I prefer a simple Python-like numbering scheme, where the second digit denotes significant changes (every 6 months?) and the third digit (plus alpha, beta, rc1, rc2, rc3, ... suffixes) refers to bug fixes that don't break much code. I think such numbering scheme is also able to make D look a little more mature and a bit more "professional". I also think it's a bad idea to create a "D3", at the moment. This means I suggest to eventually merge in the Stable-D all the changes of Development-D (unless testing of the Development version shows that it's better to abandon an idea in both D2 branches). I suggest to release Development-D quite often, like every 20-35 days, if it's possible. The presence of Development-D should allow for a more relaxed development, bug fixing and more. There are several things to fix. One of such possible changes is to remove the inliner from the D front-end (because ldc2 and gdc2 don't use it). Making the front-end a slimmer is good. There are other changes worth considering, like aligning D ABI and function calls (as other compilers refuse or can't do those things). LDC2 will be probably quite used on Windows64bit. Patches for Development-D should work in both D2 versions, unless the changes are about features not yet present in Stable-D. For simplicity I think the first thing to do to go toward the first Stable-D version should be strip away the D1 parts from the D2 Git sources, to clean and shorten the D2 code and make its updates simpler. As others have said I think it's better to not keep a single Development-D trunk, but branch it when new features (or significant changes) are developed (like UDA). Bye, bearophile
Nov 28 2012
next sibling parent reply "ixid" <nuaccount gmail.com> writes:
On Wednesday, 28 November 2012 at 15:32:47 UTC, bearophile wrote:

 I also think it's a bad idea to create a "D3", at the moment.
I think it's a bad idea to create a D3 ever. The language must not remain an eternal language tinkering project, it must be committed to to create a long-lasting and stable platform that settles down, otherwise it will remain forever peripheral. Are there really areas which are so terrible and unfixable in D2 that a D3 would be required?
Nov 28 2012
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Wednesday, November 28, 2012 16:49:40 ixid wrote:
 On Wednesday, 28 November 2012 at 15:32:47 UTC, bearophile wrote:
 I also think it's a bad idea to create a "D3", at the moment.
I think it's a bad idea to create a D3 ever. The language must not remain an eternal language tinkering project, it must be committed to to create a long-lasting and stable platform that settles down, otherwise it will remain forever peripheral. Are there really areas which are so terrible and unfixable in D2 that a D3 would be required?
Every language ends up with stuff that's unfixable without breaking backwards compatibility, and if those changes are large enough, you need a new version of the language (or a new language) which is not intended to be compatibile with the previous one (as opposed to trying to transition in the breakage - which doesn't work at all if you refuse to break backwards compatibility at all like languages such as C++ typically do). Other languages have created new versions which were not backwards compatible (e.g. python 3). But it's not the sort of thing that you do often, and it's not the sort of thing that you do lightly. Certainly, it's not something that we should be doing any time soon - or even _think_ about doing any time soon. It's years off at the earliest. And whether it makes any sense at that point needs to be examined in detail then. We can't possibly know what the situation will be at that point. So, I'm not at all prepared to say that there should never be a D3, but I don't think that it's something that's even vaguely on the table at this point. It's an issue to be discussed years from now after D2 has long since become stable and is heavily used. - Jonathan M Davis
Nov 28 2012
parent Walter Bright <newshound2 digitalmars.com> writes:
Right on, Jonathan.
Nov 28 2012
prev sibling next sibling parent 1100110 <0b1100110 gmail.com> writes:
On 11/28/2012 09:32 AM, bearophile wrote:
 Walter Bright:

 I can see creating a stable D2 and a forward D2 for 6 months at a time
 or so, as has been proposed here. I think that's a good idea. But only
 after D1 is no longer supported.
I am OK with such ideas. Below there are some musings. How do you want to call (release numbers) those two D2 versions (Stable-D and Development-D)? I prefer a simple Python-like numbering scheme, where the second digit denotes significant changes (every 6 months?) and the third digit (plus alpha, beta, rc1, rc2, rc3, ... suffixes) refers to bug fixes that don't break much code. I think such numbering scheme is also able to make D look a little more mature and a bit more "professional". I also think it's a bad idea to create a "D3", at the moment. This means I suggest to eventually merge in the Stable-D all the changes of Development-D (unless testing of the Development version shows that it's better to abandon an idea in both D2 branches). I suggest to release Development-D quite often, like every 20-35 days, if it's possible. The presence of Development-D should allow for a more relaxed development, bug fixing and more. There are several things to fix. One of such possible changes is to remove the inliner from the D front-end (because ldc2 and gdc2 don't use it). Making the front-end a slimmer is good. There are other changes worth considering, like aligning D ABI and function calls (as other compilers refuse or can't do those things). LDC2 will be probably quite used on Windows64bit. Patches for Development-D should work in both D2 versions, unless the changes are about features not yet present in Stable-D. For simplicity I think the first thing to do to go toward the first Stable-D version should be strip away the D1 parts from the D2 Git sources, to clean and shorten the D2 code and make its updates simpler. As others have said I think it's better to not keep a single Development-D trunk, but branch it when new features (or significant changes) are developed (like UDA). Bye, bearophile
A monthly 'beta' with a twice yearly stable release sounds good to me. It would be even better if we had a tool that attempted to automatically fix minor breaking changes. (for the stable of course.) To use an example from another thread, func(auto const ref var) doesn't work, but func(auto ref var) does. It would be relatively trivial to strip the const if that was one of the breaking changes.
Nov 28 2012
prev sibling parent 1100110 <0b1100110 gmail.com> writes:
On 11/28/2012 09:32 AM, bearophile wrote:
 Walter Bright:

 I can see creating a stable D2 and a forward D2 for 6 months at a time
 or so, as has been proposed here. I think that's a good idea. But only
 after D1 is no longer supported.
I am OK with such ideas. Below there are some musings. How do you want to call (release numbers) those two D2 versions (Stable-D and Development-D)? I prefer a simple Python-like numbering scheme, where the second digit denotes significant changes (every 6 months?) and the third digit (plus alpha, beta, rc1, rc2, rc3, ... suffixes) refers to bug fixes that don't break much code. I think such numbering scheme is also able to make D look a little more mature and a bit more "professional". I also think it's a bad idea to create a "D3", at the moment. This means I suggest to eventually merge in the Stable-D all the changes of Development-D (unless testing of the Development version shows that it's better to abandon an idea in both D2 branches). I suggest to release Development-D quite often, like every 20-35 days, if it's possible. The presence of Development-D should allow for a more relaxed development, bug fixing and more. There are several things to fix. One of such possible changes is to remove the inliner from the D front-end (because ldc2 and gdc2 don't use it). Making the front-end a slimmer is good. There are other changes worth considering, like aligning D ABI and function calls (as other compilers refuse or can't do those things). LDC2 will be probably quite used on Windows64bit. Patches for Development-D should work in both D2 versions, unless the changes are about features not yet present in Stable-D. For simplicity I think the first thing to do to go toward the first Stable-D version should be strip away the D1 parts from the D2 Git sources, to clean and shorten the D2 code and make its updates simpler.
Added to my things first list.
 As others have said I think it's better to not keep a single
 Development-D trunk, but branch it when new features (or significant
 changes) are developed (like UDA).
 Bye,
 bearophile
Nov 29 2012
prev sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday, November 29, 2012 00:35:55 Walter Bright wrote:
 I can see creating a stable D2 and a forward D2 for 6 months at a time
 or so, as has been proposed here. I think that's a good idea. But only
 after D1 is no longer supported.
Well, then we're about to reach the point when it's ripe to do that, because D1 is about to no longer be supported. With the beta for 2.061 (whenever that happens), we can adjust how we do the beta process to properly use branches, and then we can adjust how we deal with stable and development branches of D2 for future releases. - Jonathan M Davis
Nov 28 2012
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-11-28 17:31, Jonathan M Davis wrote:

 Well, then we're about to reach the point when it's ripe to do that, because
 D1 is about to no longer be supported. With the beta for 2.061 (whenever that
 happens), we can adjust how we do the beta process to properly use branches,
 and then we can adjust how we deal with stable and development branches of D2
 for future releases.
We said the same thing before the 2.060 release. And most likely before the 2.059 release as well. -- /Jacob Carlborg
Nov 28 2012
parent reply 1100110 <0b1100110 gmail.com> writes:
On 11/28/2012 01:30 PM, Jacob Carlborg wrote:
 On 2012-11-28 17:31, Jonathan M Davis wrote:

 Well, then we're about to reach the point when it's ripe to do that,
 because
 D1 is about to no longer be supported. With the beta for 2.061
 (whenever that
 happens), we can adjust how we do the beta process to properly use
 branches,
 and then we can adjust how we deal with stable and development
 branches of D2
 for future releases.
We said the same thing before the 2.060 release. And most likely before the 2.059 release as well.
Soo.... Theoretically Speaking. If I were to create an Organization on Github for the management of stable D versions, would you work on it?
Nov 28 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-11-28 20:54, 1100110 wrote:

 Soo....  Theoretically Speaking.

 If I were to create an Organization on Github for the management of
 stable D versions, would you work on it?
Yes, theoretically speaking. Unfortunately I don't have the time to do that. -- /Jacob Carlborg
Nov 28 2012
parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
On 28 November 2012 20:15, Jacob Carlborg <doob me.com> wrote:
 On 2012-11-28 20:54, 1100110 wrote:

 Soo....  Theoretically Speaking.

 If I were to create an Organization on Github for the management of
 stable D versions, would you work on it?
Yes, theoretically speaking. Unfortunately I don't have the time to do that. -- /Jacob Carlborg
So the plans of a stable releases branch never came into fruition? -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Nov 28 2012
next sibling parent reply 1100110 <0b1100110 gmail.com> writes:
On 11/28/2012 02:48 PM, Iain Buclaw wrote:
 On 28 November 2012 20:15, Jacob Carlborg<doob me.com>  wrote:
 On 2012-11-28 20:54, 1100110 wrote:

 Soo....  Theoretically Speaking.

 If I were to create an Organization on Github for the management of
 stable D versions, would you work on it?
Yes, theoretically speaking. Unfortunately I don't have the time to do that. -- /Jacob Carlborg
So the plans of a stable releases branch never came into fruition?
https://github.com/D-Programming-Language-Stable/dmd Phobos and druntime are also in there. Right now I'm just trying to figure out how to organize it.
Nov 28 2012
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/29/2012 8:10 AM, 1100110 wrote:
 https://github.com/D-Programming-Language-Stable/dmd

 Phobos and druntime are also in there.

 Right now I'm just trying to figure out how to organize it.
I think it's great that you're stepping up. But why do it as a separate github repository rather than a branch on the main one?
Nov 28 2012
next sibling parent 1100110 <0b1100110 gmail.com> writes:
On 11/28/2012 04:40 PM, Walter Bright wrote:
 On 11/29/2012 8:10 AM, 1100110 wrote:
 https://github.com/D-Programming-Language-Stable/dmd

 Phobos and druntime are also in there.

 Right now I'm just trying to figure out how to organize it.
I think it's great that you're stepping up. But why do it as a separate github repository rather than a branch on the main one?
I don't have commit privs on the main repo. =P So the easiest way is to fork and submit a pull request. I'm sure I could do that manually, but github makes that part a little easier. Don't worry, I had planned on pushing upstream. The extra repo is mainly for my sake. I get a nice clean slate to mark up anyway i want. I can make little notes to myself with a personal issue tracker and such. Plus this way it's easier to get others to help out. We can collaborate on one repo before submitting the changes. But if you want to go ahead and create the stable branch for me, that'd give me a head start.
Nov 28 2012
prev sibling parent reply 1100110 <0b1100110 gmail.com> writes:
On 11/28/2012 04:40 PM, Walter Bright wrote:
 On 11/29/2012 8:10 AM, 1100110 wrote:
 https://github.com/D-Programming-Language-Stable/dmd

 Phobos and druntime are also in there.

 Right now I'm just trying to figure out how to organize it.
I think it's great that you're stepping up. But why do it as a separate github repository rather than a branch on the main one?
Oh! while I have your attention... Looking at the makefiles for DMD, all of them are set to build 32bit by default. Usually that is unset, and the environment that you are compiling in dictates which one is implicitly chosen. Why have it set to build 32 by default? It's not an issue or anything, but it's been a long time since I've had a setup capable of build 32bit apps easily. I always have to change that. Is there any particular reason that that option is set rather than unset?
Nov 28 2012
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Nov 28, 2012 at 06:31:45PM -0600, 1100110 wrote:
[...]
 Oh! while I have your attention...  Looking at the makefiles for
 DMD, all of them are set to build 32bit by default.  Usually that is
 unset, and the environment that you are compiling in dictates which
 one is implicitly chosen.
 
 Why have it set to build 32 by default?  It's not an issue or
 anything, but it's been a long time since I've had a setup capable
 of build  32bit apps easily.  I always have to change that.  Is
 there any particular reason that that option is set rather than
 unset?
Rarely known fact: you can invoke make like this: make -f posix.mak MODEL=64 There is no need to change the environment. (I don't know about Windows make, but I suspect something similar, if not the same, is possible.) T -- There is no gravity. The earth sucks.
Nov 28 2012
next sibling parent 1100110 <0b1100110 gmail.com> writes:
On 11/28/2012 06:50 PM, H. S. Teoh wrote:
 On Wed, Nov 28, 2012 at 06:31:45PM -0600, 1100110 wrote:
 [...]
 Oh! while I have your attention...  Looking at the makefiles for
 DMD, all of them are set to build 32bit by default.  Usually that is
 unset, and the environment that you are compiling in dictates which
 one is implicitly chosen.

 Why have it set to build 32 by default?  It's not an issue or
 anything, but it's been a long time since I've had a setup capable
 of build  32bit apps easily.  I always have to change that.  Is
 there any particular reason that that option is set rather than
 unset?
Rarely known fact: you can invoke make like this: make -f posix.mak MODEL=64 There is no need to change the environment. (I don't know about Windows make, but I suspect something similar, if not the same, is possible.) T
I know, I just have a bad habit of digging through makefiles and such before Ill run them. When its literally right under the cursor its just easier to edit it. I was really just curious why it wasn't left undefined. It *seems* to be building fine without that option defined, and with the way Linux is going I simply cannot believe that I'm the only one for whom that messes up a default build.
Nov 28 2012
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/29/2012 11:50 AM, H. S. Teoh wrote:
 Rarely known fact: you can invoke make like this:

 	make -f posix.mak MODEL=64

 There is no need to change the environment.

 (I don't know about Windows make, but I suspect something similar, if
 not the same, is possible.)
Not only is it similar, it's exactly the same.
Nov 28 2012
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Nov 29, 2012 at 01:11:32PM +1100, Walter Bright wrote:
 On 11/29/2012 11:50 AM, H. S. Teoh wrote:
Rarely known fact: you can invoke make like this:

	make -f posix.mak MODEL=64

There is no need to change the environment.

(I don't know about Windows make, but I suspect something similar, if
not the same, is possible.)
Not only is it similar, it's exactly the same.
[...] Ah, so it isn't a GNU make thing. I tend to run into those every now and then. T -- Two American lawyers went down to the beach for a swim. Seeing a canoe rental nearby, one asked the other, "Roe, or Wade?"
Nov 28 2012
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/29/2012 11:31 AM, 1100110 wrote:
 Why have it set to build 32 by default?  It's not an issue or anything,
 but it's been a long time since I've had a setup capable of build  32bit
 apps easily.  I always have to change that.  Is there any particular
 reason that that option is set rather than unset?
Something has to be the default, and that dates back to when D was only implemented on 32 bit targets. Anyhow, I usually use a custom makefile to drive the dmd makefiles, setting the various macros as appropriate for my setup, so the defaults are kinda irrelevant.
Nov 28 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-11-29 01:50, Walter Bright wrote:

 Something has to be the default, and that dates back to when D was only
 implemented on 32 bit targets.
How about defaulting to the architecture one is building on? -- /Jacob Carlborg
Nov 28 2012
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday, November 29, 2012 08:45:53 Jacob Carlborg wrote:
 On 2012-11-29 01:50, Walter Bright wrote:
 Something has to be the default, and that dates back to when D was only
 implemented on 32 bit targets.
How about defaulting to the architecture one is building on?
I believe that that's what most applications do when you build them - at least in *nix land. There, it really doesn't make sense to assume either 32-bit or 64-bit. - Jonathan M Davis
Nov 28 2012
parent 1100110 <0b1100110 gmail.com> writes:
On 11/29/2012 01:52 AM, Jonathan M Davis wrote:
 On Thursday, November 29, 2012 08:45:53 Jacob Carlborg wrote:
 On 2012-11-29 01:50, Walter Bright wrote:
 Something has to be the default, and that dates back to when D was only
 implemented on 32 bit targets.
How about defaulting to the architecture one is building on?
I believe that that's what most applications do when you build them - at least in *nix land. There, it really doesn't make sense to assume either 32-bit or 64-bit. - Jonathan M Davis
Simply leaving MODEL= blank does just that.
Nov 29 2012
prev sibling parent Manu <turkeyman gmail.com> writes:
On 28 November 2012 23:10, 1100110 <0b1100110 gmail.com> wrote:

 On 11/28/2012 02:48 PM, Iain Buclaw wrote:

 On 28 November 2012 20:15, Jacob Carlborg<doob me.com>  wrote:

 On 2012-11-28 20:54, 1100110 wrote:


  Soo....  Theoretically Speaking.
 If I were to create an Organization on Github for the management of
 stable D versions, would you work on it?
Yes, theoretically speaking. Unfortunately I don't have the time to do that. -- /Jacob Carlborg
So the plans of a stable releases branch never came into fruition? https://github.com/D-**Programming-Language-Stable/**dmd<https://github.com/D-Programming-Language-Stable/dmd>
Phobos and druntime are also in there. Right now I'm just trying to figure out how to organize it.
Perhaps this is a really stupid question... But what's wrong with using branches in the main DMD repo?
Nov 29 2012
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-11-28 21:48, Iain Buclaw wrote:

 So the plans of a stable releases branch never came into fruition?
Not that I've heard of. -- /Jacob Carlborg
Nov 28 2012
prev sibling parent reply 1100110 <0b1100110 gmail.com> writes:
On 11/28/2012 02:48 PM, Iain Buclaw wrote:
 On 28 November 2012 20:15, Jacob Carlborg<doob me.com>  wrote:
 On 2012-11-28 20:54, 1100110 wrote:

 Soo....  Theoretically Speaking.

 If I were to create an Organization on Github for the management of
 stable D versions, would you work on it?
Yes, theoretically speaking. Unfortunately I don't have the time to do that. -- /Jacob Carlborg
So the plans of a stable releases branch never came into fruition?
Would you be interested in helping?
Nov 28 2012
next sibling parent "cal" <callumenator gmail.com> writes:
On Wednesday, 28 November 2012 at 21:40:14 UTC, 1100110 wrote:
 On 11/28/2012 02:48 PM, Iain Buclaw wrote:
 So the plans of a stable releases branch never came into 
 fruition?
Would you be interested in helping?
Wasn't this the same idea? https://github.com/dlang-stable
Nov 28 2012
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-11-28 22:40, 1100110 wrote:

 Would you be interested in helping?
Yes, but as I said, unfortunately I don't have the time. I also don't think I have enough knowledge about the compiler to do that. Sure I can always learn but I think I can put my time to better use in other D related projects, like I already do. -- /Jacob Carlborg
Nov 28 2012
prev sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 28 November 2012 21:40, 1100110 <0b1100110 gmail.com> wrote:
 On 11/28/2012 02:48 PM, Iain Buclaw wrote:
 On 28 November 2012 20:15, Jacob Carlborg<doob me.com>  wrote:
 On 2012-11-28 20:54, 1100110 wrote:


 Soo....  Theoretically Speaking.

 If I were to create an Organization on Github for the management of
 stable D versions, would you work on it?
Yes, theoretically speaking. Unfortunately I don't have the time to do that. -- /Jacob Carlborg
So the plans of a stable releases branch never came into fruition?
Would you be interested in helping?
I would support it if were made available. To do double work is probably out of the question. -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Nov 29 2012
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/29/2012 3:31 AM, Jonathan M Davis wrote:
 Well, then we're about to reach the point when it's ripe to do that, because
 D1 is about to no longer be supported. With the beta for 2.061 (whenever that
 happens), we can adjust how we do the beta process to properly use branches,
 and then we can adjust how we deal with stable and development branches of D2
 for future releases.
My thoughts, too. BTW, just so everyone knows, I am currently in Melbourne at the YOW conference. It's the start of a 3 city tour, so I won't get home until Dec. 8. The hotel internet connection is not much more suitable than for email and newsgroups, and my travel laptop is not well suited for dev, so aside from my conference obligations I intend to be doing things like D articles, learning new stuff, and other back-and-fill work until then. BTW, it's a great conference. There are a lot of freakin' smart people here, which always makes things a joy.
Nov 28 2012
next sibling parent reply Danni Coy <danni.coy gmail.com> writes:
Holy crap I had no idea that this conference even existed. It turns out I
am in melbourne for the next few days for entirely different reasons. Manu
thinks I should buy you a drink (i concur)...

I am generally in favour of the language being good rather than being
stable at this point in time. This is general keeping with the philosophy
that the right way do do things should be the easiest way to do things.



On Thu, Nov 29, 2012 at 8:37 AM, Walter Bright
<newshound2 digitalmars.com>wrote:

 On 11/29/2012 3:31 AM, Jonathan M Davis wrote:

 Well, then we're about to reach the point when it's ripe to do that,
 because
 D1 is about to no longer be supported. With the beta for 2.061 (whenever
 that
 happens), we can adjust how we do the beta process to properly use
 branches,
 and then we can adjust how we deal with stable and development branches
 of D2
 for future releases.
My thoughts, too. BTW, just so everyone knows, I am currently in Melbourne at the YOW conference. It's the start of a 3 city tour, so I won't get home until Dec. 8. The hotel internet connection is not much more suitable than for email and newsgroups, and my travel laptop is not well suited for dev, so aside from my conference obligations I intend to be doing things like D articles, learning new stuff, and other back-and-fill work until then. BTW, it's a great conference. There are a lot of freakin' smart people here, which always makes things a joy.
Nov 29 2012
parent Walter Bright <newshound2 digitalmars.com> writes:
On 11/29/2012 8:52 PM, Danni Coy wrote:
 Holy crap I had no idea that this conference even existed. It turns out
 I am in melbourne for the next few days for entirely different reasons.
 Manu thinks I should buy you a drink (i concur)...
No need, the booze flows freely here! But hey, drop by. It's in the Sebel Albert Park Hotel.
Nov 29 2012
prev sibling parent Manu <turkeyman gmail.com> writes:
On 29 November 2012 11:52, Danni Coy <danni.coy gmail.com> wrote:

 Holy crap I had no idea that this conference even existed. It turns out I
 am in melbourne for the next few days for entirely different reasons. Manu
 thinks I should buy you a drink (i concur)...
Yes, and make sure to remind him that it's all your fault! ;) I am generally in favour of the language being good rather than being
 stable at this point in time. This is general keeping with the philosophy
 that the right way do do things should be the easiest way to do things.



 On Thu, Nov 29, 2012 at 8:37 AM, Walter Bright <newshound2 digitalmars.com
 wrote:
 On 11/29/2012 3:31 AM, Jonathan M Davis wrote:

 Well, then we're about to reach the point when it's ripe to do that,
 because
 D1 is about to no longer be supported. With the beta for 2.061 (whenever
 that
 happens), we can adjust how we do the beta process to properly use
 branches,
 and then we can adjust how we deal with stable and development branches
 of D2
 for future releases.
My thoughts, too. BTW, just so everyone knows, I am currently in Melbourne at the YOW conference. It's the start of a 3 city tour, so I won't get home until Dec. 8. The hotel internet connection is not much more suitable than for email and newsgroups, and my travel laptop is not well suited for dev, so aside from my conference obligations I intend to be doing things like D articles, learning new stuff, and other back-and-fill work until then. BTW, it's a great conference. There are a lot of freakin' smart people here, which always makes things a joy.
Nov 29 2012
prev sibling parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
On Wednesday, 28 November 2012 at 13:15:26 UTC, Jacob Carlborg 
wrote:
 On 2012-11-28 13:41, Walter Bright wrote:

 On the other hand, many people were unhappy with my position 
 of "no
 breaking changes at all outside of clear bug fixes" to D1, 
 which also
 implied "no language enhancements". There were many 
 enhancements to the
 code generation, new platforms, etc., and many CTFE 
 improvements (which
 I more or less regarded as bug fixing). There were also no 
 changes
 allowed that affected binary compatibility.
Please, please try and understand. It's not breaking changes in it self that is the problem. It's how they're handled. Many people has also talked about something in between D1 and D2, D1.5 or similar. Which would contain bug fixes and new backwards compilable changes.
For what it's worth, I agree. I think that the current "core" developers of D are exceptional programmers, with a very astute eye as to what makes a good programming language and the skills to implement it. That said, the management of D is relatively poor. For any programming language to make headway in the real world (i.e. not in the language aficionado's playground) it HAS to have some form of stable branch *. The documentation MUST be up to date and complete for that stable branch, including all the things that are wrong with it! A path I see 1. Redirect current efforts towards stability **, aiming to produce a major release of DMD+druntime+phobos with complete and __honest__ documentation (i.e. admitting that something doesn't quite work right, "use at your own risk"). Then, make an aggressive push to get that stable release into use in mainstream, large-scale projects, which given D's power, combined with stability, should be much easier than before. 2. Someone takes on a significant managerial/admin position, who has responsibility over the documentation and stable releases of D. This would be a pretty unexciting job, so it probably needs to be paid in order to get it done well. After part 1, finding some money shouldn't be so hard. My fear is that if the D rocket doesn't lift off now, it never really will. * Look at python for example. Effectively the entire language is branched every so often and stabilised, including the standard library. Major release numbers signify a particular "branch", which is then pushed towards it's most stable state, while new features and significant code-breaking changes go in the next version number. ** Please note that I do NOT mean making the language work perfectly, fixing every bug. I mean fixing a lot of the low hanging fruit and properly documenting the problems that remain.
Nov 28 2012
next sibling parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
On Wednesday, 28 November 2012 at 14:34:12 UTC, John Colvin wrote:
 On Wednesday, 28 November 2012 at 13:15:26 UTC, Jacob Carlborg 
 wrote:
 On 2012-11-28 13:41, Walter Bright wrote:

 On the other hand, many people were unhappy with my position 
 of "no
 breaking changes at all outside of clear bug fixes" to D1, 
 which also
 implied "no language enhancements". There were many 
 enhancements to the
 code generation, new platforms, etc., and many CTFE 
 improvements (which
 I more or less regarded as bug fixing). There were also no 
 changes
 allowed that affected binary compatibility.
Please, please try and understand. It's not breaking changes in it self that is the problem. It's how they're handled. Many people has also talked about something in between D1 and D2, D1.5 or similar. Which would contain bug fixes and new backwards compilable changes.
For what it's worth, I agree. blah blah blah
sorry, I mean to edit out the bit about D1.5 in Jacob's post, not sure I fully understand what that would mean enough to agree with it
Nov 28 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-11-28 15:36, John Colvin wrote:

 sorry, I mean to edit out the bit about D1.5 in Jacob's post, not sure I
 fully understand what that would mean enough to agree with it
Just as with D1 now, it only receives bug fixes. But it would also receive new features which are backwards compatible. I.e. adding a completely new module to the standard library is backwards compatible change. -- /Jacob Carlborg
Nov 28 2012
prev sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Wednesday, November 28, 2012 15:34:11 John Colvin wrote:
 * Look at python for example. Effectively the entire language is
 branched every so often and stabilised, including the standard
 library. Major release numbers signify a particular "branch",
 which is then pushed towards it's most stable state, while new
 features and significant code-breaking changes go in the next
 version number.
I don't know if we want to set up our process to match python's (I don't know their process well enough to make that evaluation), but I definitely think that we need to move to something similar, and projects such as python could provide a good model to base what we do off of. - Jonathan M Davis
Nov 28 2012
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/28/12 3:01 AM, Jacob Carlborg wrote:
 TDPL was release way, way too soon. It was written before many of the
 features were even implemented. Then at a later stage "Whoops, this
 apparently doesn't work, we need to break TDPL".
I disagree. Aside from a few details, the language described by TDPL is implementable. The problem becomes when TDPL gets in competition with incorrect code that currently compiles and runs although it shouldn't. Andrei
Nov 28 2012
parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Wednesday, November 28, 2012 07:44:39 Andrei Alexandrescu wrote:
 On 11/28/12 3:01 AM, Jacob Carlborg wrote:
 TDPL was release way, way too soon. It was written before many of the
 features were even implemented. Then at a later stage "Whoops, this
 apparently doesn't work, we need to break TDPL".
I disagree. Aside from a few details, the language described by TDPL is implementable. The problem becomes when TDPL gets in competition with incorrect code that currently compiles and runs although it shouldn't.
That's mostly true, but there are some features which have required further ironing out even if TDPL is mostly correct about them still (e.g. pure and shared), and some features _still_ aren't properly implemented (e.g. synchronized and alias this). I'm not about to say that TDPL was released too early (it's been a _great_ resource and has undoubtedly helped the community grow), but at the same time, it doesn't quite represent what the language actually is, and we're slow at catching up with it. So, in that sense, if TDPL is meant to be a definitive resource, it would have been nice to have the implementation be closer to where TDPL is before having released it However, a _big_ benefit from having not delayed its release was that that a lot of stuff stopped changing after that. We stopped making huge, incompatible changes from release to release of the compiler. We didn't stop making breaking changes, but for the most part, we stopped trying to design the language and instead have focused on finishing implementing it. All of the design work that has happened since then has either fixed a pressing problem caused by the current design (e.g. weak purity) or introduced new, compatible features (e.g. SIMD). We're no longer doing stuff like changing how operator overloading works just because we came up with a cooler, better way to do it. - Jonathan M Davis
Nov 28 2012
prev sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
SiegeLord:

 With that kind of attitude D2 will never stabilize.
Currently in D there are unfinished parts like vector operations that are not finished, shared that maybe needs to be redesigned, foreach loops and switch statements that need some design fixes, but also its standard library has rebindable, emplace, Typedef, Nullable and Algebraic that are not good enough and need improvements or rethinking. Plus some missing collections and memory allocators. Plus there are several corner cases that must be addressed, I am following Bugzilla closely and if you want I can list you one hundred of significant bugs. Fixing some of those "bugs" will break user D2 code. Not fixing those bugs will be a worse fate. D is a quite complex language, composed of many parts, and Walter is not just designing a language and developing a front-end, but he's also keeping its back-end, there is also the standard library, and the garbage collector. And the amount of work force is limited. So D develops and stabilize rather slowly. Developing D takes many years. I think there is no escape from this. On the other hand I used to find a significant new bug every 20-30 lines of my D2 code, this today happens much more rarely. Bye, bearophile
Nov 28 2012
prev sibling parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Wednesday, 28 November 2012 at 02:29:12 UTC, bearophile wrote:
 SiegeLord:

 I think that unless people responsible for these things get 
 their act together and stabilize D2 against these issues, D1 
 support should be extended until that happens.
It will take some more years to see D2 "stabilized" like that. The decision to discontinue D1 has some disadvantages, but keeping D1 updated uses some work time that could be (better) spent improving D2. Bye, bearophile
The problem we have with this situation is that language users will just run away to more stable languages. Many people need upper management agreement for the set of languages they use, if suggesting D might cause them to risk their job, they won't do it. -- Paulo
Nov 27 2012
next sibling parent reply Manu <turkeyman gmail.com> writes:
On 28 November 2012 09:47, Paulo Pinto <pjmlp progtools.org> wrote:

 On Wednesday, 28 November 2012 at 02:29:12 UTC, bearophile wrote:

 SiegeLord:

  I think that unless people responsible for these things get their act
 together and stabilize D2 against these issues, D1 support should be
 extended until that happens.
It will take some more years to see D2 "stabilized" like that. The decision to discontinue D1 has some disadvantages, but keeping D1 updated uses some work time that could be (better) spent improving D2. Bye, bearophile
The problem we have with this situation is that language users will just run away to more stable languages.
If D stabilised on exactly the feature set it offers right now (or even 3 months ago), I wouldn't be interested. The lowest level is brittle, and the high level is still missing a couple of little details (rvalues -> ref is the key one for me). D's fluidity is actually one of it's biggest selling points as far as I'm concerned. D seems to accept that mistakes can be fixed and improvements can be made, and it should embrace that to an extent, or you end up with C++ long term. I think the best approach is one that others have suggested, 2 branches, 'stable' which is maintained for 6-12 months, and only receives non-breaking fixes after they've been tested for a while, and 'dev', which users accept may receive breaking changes at any time. Those users will be happy to adapt their code as the language moves forward, as I am. You choose the branch that applies to your business, and then you have no reason to complain. The current situation where one branch adopting either policy (and seemingly changing which policy it subscribes to from day to day) will alienate the other camp, and is obviously unworkable. Under a 2 branch system, the stable crew will still have to update from time to time, but they can do it in one lump far less often, and that should cause a lot less trouble for them. D should have 3 version digits: D2.6.1, the second digit representing the last 'stable' codepoint. Many people need upper management agreement for the set of languages they
 use, if suggesting D might cause them to risk their job, they won't do it.
I feel this personally.
Nov 28 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-11-28 12:48, Manu wrote:


 I think the best approach is one that others have suggested, 2 branches,
 'stable' which is maintained for 6-12 months, and only receives
 non-breaking fixes after they've been tested for a while, and 'dev',
 which users accept may receive breaking changes at any time. Those users
 will be happy to adapt their code as the language moves forward, as I am.
I completely agree, it's not rocket science. -- /Jacob Carlborg
Nov 28 2012
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Nov 28, 2012 at 01:43:53PM +0100, Jacob Carlborg wrote:
 On 2012-11-28 12:48, Manu wrote:
I think the best approach is one that others have suggested, 2
branches, 'stable' which is maintained for 6-12 months, and only
receives non-breaking fixes after they've been tested for a while,
and 'dev', which users accept may receive breaking changes at any
time. Those users will be happy to adapt their code as the language
moves forward, as I am.
I completely agree, it's not rocket science.
[...] +1. And with the code repo in git, this is not hard to do at all. And here's a further suggestion: somebody else other than Walter should maintain the 'stable' branch, so that Walter can continue working on bleeding-edge stuff, without having to split his time with maintaining yet another branch. Preferably have a team of 2 or 3 who track the 'unstable' git commits, and decide which ones are safe to pull into the 'stable' branch. T -- "I'm not childish; I'm just in touch with the child within!" - RL
Nov 28 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-11-28 18:53, H. S. Teoh wrote:

 +1.

 And with the code repo in git, this is not hard to do at all.

 And here's a further suggestion: somebody else other than Walter should
 maintain the 'stable' branch, so that Walter can continue working on
 bleeding-edge stuff, without having to split his time with maintaining
 yet another branch. Preferably have a team of 2 or 3 who track the
 'unstable' git commits, and decide which ones are safe to pull into the
 'stable' branch.
Haven't we already agreed on this, that last time this discussion came up. Someone volunteered to keep a fork of the D projects and slowly merge changes. The releases should of course be based on this fork. -- /Jacob Carlborg
Nov 28 2012
prev sibling parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 11/28/2012 12:48 PM, Manu wrote:
 If D stabilised on exactly the feature set it offers right now (or even 3
months
 ago), I wouldn't be interested. The lowest level is brittle, and the high level
 is still missing a couple of little details (rvalues -> ref is the key one for
me).
 D's fluidity is actually one of it's biggest selling points as far as I'm
 concerned. D seems to accept that mistakes can be fixed and improvements can be
 made, and it should embrace that to an extent, or you end up with C++ long
term.

 I think the best approach is one that others have suggested, 2 branches,
 'stable' which is maintained for 6-12 months, and only receives non-breaking
 fixes after they've been tested for a while, and 'dev', which users accept may
 receive breaking changes at any time. Those users will be happy to adapt their
 code as the language moves forward, as I am.
I'd agree but with one caveat -- how do you handle the case of the standard library, or indeed any other library? Obviously, every library developer can choose between maintaining a version that works with stable only; maintaining a stable and 'bleeding-edge' version; or just bleeding edge. Presumably for Phobos you'd choose the second of these. But then, how do you handle _new_ functionality that may or may not depend on breaking changes to the language? Given that Phobos is still a moving target with new functionality being added on a regular basis, it could be a bit of a disappointment to have to wait as long as 6 months to see the latest new features. The same also applies to the downstream compilers like GDC and LDC -- it would be frustrating to have to wait so long to see new functionality available here. One way to handle that might be to first do the work to properly separate out the frontend, so that updates can be merged immediately into GDC/LDC's dev versions rather than having to wait for each release. Finally, even in dev I think it would be useful to still have some formal notice of deprecation, so that there's time to anticipate changes. I'd rather not just wake up one morning and find that my code no longer compiles!
Nov 28 2012
parent reply 1100110 <0b1100110 gmail.com> writes:
On 11/28/2012 12:05 PM, Joseph Rushton Wakeling wrote:
 On 11/28/2012 12:48 PM, Manu wrote:
 If D stabilised on exactly the feature set it offers right now (or
 even 3 months
 ago), I wouldn't be interested. The lowest level is brittle, and the
 high level
 is still missing a couple of little details (rvalues -> ref is the key
 one for me).
 D's fluidity is actually one of it's biggest selling points as far as I'm
 concerned. D seems to accept that mistakes can be fixed and
 improvements can be
 made, and it should embrace that to an extent, or you end up with C++
 long term.

 I think the best approach is one that others have suggested, 2 branches,
 'stable' which is maintained for 6-12 months, and only receives
 non-breaking
 fixes after they've been tested for a while, and 'dev', which users
 accept may
 receive breaking changes at any time. Those users will be happy to
 adapt their
 code as the language moves forward, as I am.
I'd agree but with one caveat -- how do you handle the case of the standard library, or indeed any other library? Obviously, every library developer can choose between maintaining a version that works with stable only; maintaining a stable and 'bleeding-edge' version; or just bleeding edge. Presumably for Phobos you'd choose the second of these. But then, how do you handle _new_ functionality that may or may not depend on breaking changes to the language? Given that Phobos is still a moving target with new functionality being added on a regular basis, it could be a bit of a disappointment to have to wait as long as 6 months to see the latest new features. The same also applies to the downstream compilers like GDC and LDC -- it would be frustrating to have to wait so long to see new functionality available here. One way to handle that might be to first do the work to properly separate out the frontend, so that updates can be merged immediately into GDC/LDC's dev versions rather than having to wait for each release. Finally, even in dev I think it would be useful to still have some formal notice of deprecation, so that there's time to anticipate changes. I'd rather not just wake up one morning and find that my code no longer compiles!
A new module in Phobos is highly unlikely to break anything, So I would assume that this would count as a simple bug fix and be merged.
Nov 28 2012
next sibling parent reply eskimo <jfanatiker gmx.at> writes:
On Wed, 2012-11-28 at 13:02 -0600, 1100110 wrote:
 Given that Phobos is still a moving target with new functionality
 being
 added on a regular basis, it could be a bit of a disappointment to
have
 to wait as long as 6 months to see the latest new features. 
Well either you want stable or bleeding edge. New features need to stabilize, have bugs ironed out, might need a redesign, ... That is why they should be introduced in the unstable branch and only after some testing get into the stable branch. Stable should not only mean that you only receive breaking changes, every six months, but also that the features you use are better tested and mature than in the unstable branch. In my opinion a stable version should not receive anything but bug fixes. External libraries, most likely will sync with D's development and provide a new stable release after a new D version arrived, which then also only receives bug fixes. If you are stable, you don't have the newest and coolest features and that is a good thing. If you want them, don't use stable. Even the unstable branch should stop adding new features let's say at least three months before the next stable release, so all things in stable have been tested at least a certain minimum amount of time in unstable. (People can still work on new features, but only in separate feature branches, which will not be part of the next stable release.) Much like the Linux kernel development: Have a merge window and a stabilization phase, then the release. If you skip the _stabilization_ or even dare to merge things directly into stable, you don't have anything stable. A stable release, should in a perfect world not change at all, that's why it is stable, most bugs should have been ironed out, even before it is released. In particular a stable version should not introduce any regressions, which is very much more likely with a few months of testing. Best regards, Robert
Nov 28 2012
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
eskimo:

 Even the unstable branch should stop adding new features let's 
 say at
 least three months before the next stable release, so all 
 things in
 stable have been tested at least a certain minimum amount of 
 time in
 unstable. (People can still work on new features, but only in 
 separate
 feature branches, which will not be part of the next stable 
 release.)
Maybe there are alternative ways to do this. But generally I agree with your post and I suggest to make a little DEP out of it, or to copy your post somewhere in the Wiki, to make it the starting point (to be improved, where necessary) document for the future D development process. Bye, bearophile
Nov 28 2012
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Nov 29, 2012 at 01:51:52AM +0100, bearophile wrote:
 eskimo:
 
Even the unstable branch should stop adding new features let's say at
least three months before the next stable release, so all things in
stable have been tested at least a certain minimum amount of time in
unstable. (People can still work on new features, but only in
separate feature branches, which will not be part of the next stable
release.)
Maybe there are alternative ways to do this. But generally I agree with your post and I suggest to make a little DEP out of it, or to copy your post somewhere in the Wiki, to make it the starting point (to be improved, where necessary) document for the future D development process.
[...] I think ultimately, as Walter has said, nothing is going to change unless somebody steps up to the plate and champions the effort to make a stable branch. Writing up proposals, specs, and other docs are good in theory, but won't accomplish a thing if nobody actually *does* anything about it. I think 1100110 has stepped up to make a stable branch; let's work with him to make it actually happen. T -- "I'm running Windows '98." "Yes." "My computer isn't working now." "Yes, you already said that." -- User-Friendly
Nov 28 2012
next sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 29 November 2012 at 01:06:15 UTC, H. S. Teoh wrote:
 I think ultimately, as Walter has said, nothing is going to 
 change
 unless somebody steps up to the plate and champions the effort 
 to make a
 stable branch. Writing up proposals, specs, and other docs are 
 good in
 theory, but won't accomplish a thing if nobody actually *does* 
 anything
 about it. I think 1100110 has stepped up to make a stable 
 branch; let's
 work with him to make it actually happen.
I'm sorry, but I don't see how a champion can prevent stuff to be dropped directly into master, unless going to some extreme and sequestrate people, which is illegal in most countries.
Nov 28 2012
next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, November 29, 2012 02:13:10 deadalnix wrote:
 On Thursday, 29 November 2012 at 01:06:15 UTC, H. S. Teoh wrote:
 I think ultimately, as Walter has said, nothing is going to
 change
 unless somebody steps up to the plate and champions the effort
 to make a
 stable branch. Writing up proposals, specs, and other docs are
 good in
 theory, but won't accomplish a thing if nobody actually *does*
 anything
 about it. I think 1100110 has stepped up to make a stable
 branch; let's
 work with him to make it actually happen.
I'm sorry, but I don't see how a champion can prevent stuff to be dropped directly into master, unless going to some extreme and sequestrate people, which is illegal in most countries.
Since master will almost certainly be the development branch, I don't see how that's a problem. The stable branch will be a separate branch, and whoever is managing the stable branch will merge stuff from the master branch into it. Granted, major stuff like 64-bit Windows support and UDAs should probably be introduced on branches separate from master, and it's still a problem if they're not, but it won't affect the stable branch if they're not. - Jonathan M Davis
Nov 28 2012
parent reply "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 29 November 2012 at 01:29:12 UTC, Jonathan M Davis 
wrote:
 Since master will almost certainly be the development branch, I 
 don't see how
 that's a problem. The stable branch will be a separate branch, 
 and whoever is
 managing the stable branch will merge stuff from the master 
 branch into it.
In this case, all bug fixes are mixed with new feature and then have to be separated afterward and remerged into the stable branch. This is useless work and it is likely to cause merge conflict in the stable branch. Additionnaly, this become to really suck when several new features are dev at the same time. Finally, yhis is completely inconsistent with how github work in the first place. master make sense as an unstable branch, a release candidate, a beta or whatever, but certainly not a dev branch.
 Granted, major stuff like 64-bit Windows support and UDAs 
 should probably be
 introduced on branches separate from master, and it's still a 
 problem if
 they're not, but it won't affect the stable branch if they're 
 not.
It will become all bigfixes will be based on code that contains the new feature.
Nov 28 2012
parent reply Manu <turkeyman gmail.com> writes:
On 29 November 2012 03:48, deadalnix <deadalnix gmail.com> wrote:

 On Thursday, 29 November 2012 at 01:29:12 UTC, Jonathan M Davis wrote:

 Since master will almost certainly be the development branch, I don't see
 how

 that's a problem. The stable branch will be a separate branch, and
 whoever is
 managing the stable branch will merge stuff from the master branch into
 it.
In this case, all bug fixes are mixed with new feature and then have to be separated afterward and remerged into the stable branch. This is useless work and it is likely to cause merge conflict in the stable branch. Additionnaly, this become to really suck when several new features are dev at the same time. Finally, yhis is completely inconsistent with how github work in the first place. master make sense as an unstable branch, a release candidate, a beta or whatever, but certainly not a dev branch.
Why don't you document precisely what branches you think should exist, and the working merge/rebase policies. I'm actually very curious to know. Granted, major stuff like 64-bit Windows support and UDAs should probably
 be
 introduced on branches separate from master, and it's still a problem if
 they're not, but it won't affect the stable branch if they're not.
It will become all bigfixes will be based on code that contains the new feature.
Nov 29 2012
parent reply "foobar" <foo bar.com> writes:
On Thursday, 29 November 2012 at 09:37:57 UTC, Manu wrote:
 On 29 November 2012 03:48, deadalnix <deadalnix gmail.com> 
 wrote:

 On Thursday, 29 November 2012 at 01:29:12 UTC, Jonathan M 
 Davis wrote:

 Since master will almost certainly be the development branch, 
 I don't see
 how

 that's a problem. The stable branch will be a separate 
 branch, and
 whoever is
 managing the stable branch will merge stuff from the master 
 branch into
 it.
In this case, all bug fixes are mixed with new feature and then have to be separated afterward and remerged into the stable branch. This is useless work and it is likely to cause merge conflict in the stable branch. Additionnaly, this become to really suck when several new features are dev at the same time. Finally, yhis is completely inconsistent with how github work in the first place. master make sense as an unstable branch, a release candidate, a beta or whatever, but certainly not a dev branch.
Why don't you document precisely what branches you think should exist, and the working merge/rebase policies. I'm actually very curious to know. Granted, major stuff like 64-bit Windows support and UDAs should probably
 be
 introduced on branches separate from master, and it's still a 
 problem if
 they're not, but it won't affect the stable branch if they're 
 not.
It will become all bigfixes will be based on code that contains the new feature.
Manu: This was mentioned in the group numerous times before, here's one more time to increase awareness even more: git flow - http://nvie.com/posts/a-successful-git-branching-model/ should be easily adapted for the D development process. Walter: a champion cannot solve this issue as this requires participation of all (core) developers. Otherwise we get a _lot_ of redundant after the fact maintenance work. The only way to succeed long term is to remove all single points of failures - the single master branch on the technical side, and a single decision making person (you) on the management side. It can only be possible if you agree to relinquish some control and allow other core developers to _fully_ participate. that includes - review/pull powers, managing their own branches, taking part in the decision making process as to what feature is mature enough to be "released" on the stable branch. No champion can do any of that as it requires your agreement and participation. Until such changes happen and D becomes _a community process_ (as I see Andrei is rightfully pushing for) there is little chance of a bigger D success. Also, just to touch the multiple compiler versions overhead you mentioned - The point of maintaining multiple branches is to _minimize_ such overhead, not increase it. This allows for easier management of features, a more gradual release process to prevent regressions and breakage on the release branch, it gives _more control_ and allows for scaling of management to more developers. more branches => less work for you.
Nov 29 2012
next sibling parent eskimo <jfanatiker gmx.at> writes:
That is pretty much what I had in mind, but more concrete thought
through. I really like it :-) The only things to clear up would be, how
long must a release branch exist, before it is considered stable. Which
depends on how stable we want things to be.


On Thu, 2012-11-29 at 11:35 +0100, foobar wrote:
 This was mentioned in the group numerous times before, here's one 
 more time to increase awareness even more:
 git flow - http://nvie.com/posts/a-successful-git-branching-model/
 should be easily adapted for the D development process. 
Nov 29 2012
prev sibling next sibling parent eskimo <jfanatiker gmx.at> writes:
On Thu, 2012-11-29 at 12:45 +0100, eskimo wrote:
 That is pretty much what I had in mind, but more concrete thought
 through. I really like it :-) The only things to clear up would be, how
 long must a release branch exist, before it is considered stable. Which
 depends on how stable we want things to be.
 
 
 On Thu, 2012-11-29 at 11:35 +0100, foobar wrote:
 This was mentioned in the group numerous times before, here's one 
 more time to increase awareness even more:
 git flow - http://nvie.com/posts/a-successful-git-branching-model/
 should be easily adapted for the D development process. 
We would then simply do regular dev releases of the development branch (which is pretty much the releases we have now), so many people test the stuff. Then lots of beta releases from the release branch and after six months or so, the final stable release is made.
Nov 29 2012
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-11-29 11:35, foobar wrote:

 Walter:
 a champion cannot solve this issue as this requires participation of all
 (core) developers. Otherwise we get a _lot_ of redundant after the fact
 maintenance work. The only way to succeed long term is to remove all
 single points of failures - the single master branch on the technical
 side, and a single decision making person (you) on the management side.
 It can only be possible if you agree to relinquish some control and
 allow other core developers to _fully_ participate. that includes -
 review/pull powers, managing their own branches, taking part in the
 decision making process as to what feature is mature enough to be
 "released" on the stable branch. No champion can do any of that as it
 requires your agreement and participation.
 Until such changes happen and D becomes _a community process_ (as I see
 Andrei is rightfully pushing for) there is little chance of a bigger D
 success.

 Also, just to touch the multiple compiler versions overhead you
 mentioned - The point of maintaining multiple branches is to _minimize_
 such overhead, not increase it. This allows for easier management of
 features, a more gradual release process to prevent regressions and
 breakage on the release branch, it gives _more control_ and allows for
 scaling of management to more developers. more branches => less work for
 you.
So true. -- /Jacob Carlborg
Nov 29 2012
prev sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Nov 29, 2012 at 02:13:10AM +0100, deadalnix wrote:
 On Thursday, 29 November 2012 at 01:06:15 UTC, H. S. Teoh wrote:
I think ultimately, as Walter has said, nothing is going to change
unless somebody steps up to the plate and champions the effort to
make a stable branch. Writing up proposals, specs, and other docs are
good in theory, but won't accomplish a thing if nobody actually
*does* anything about it. I think 1100110 has stepped up to make a
stable branch; let's work with him to make it actually happen.
I'm sorry, but I don't see how a champion can prevent stuff to be dropped directly into master, unless going to some extreme and sequestrate people, which is illegal in most countries.
Huh? Who said anything about master being stable? Obviously master is unstable by definition, since that's where the development work is being done. The whole point was to introduce a stable branch where we only pull in non-breaking changes from master. T -- "Real programmers can write assembly code in any language. :-)" -- Larry Wall
Nov 28 2012
next sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 29 November 2012 at 01:30:42 UTC, H. S. Teoh wrote:
 Huh? Who said anything about master being stable? Obviously 
 master is
 unstable by definition, since that's where the development work 
 is being
 done. The whole point was to introduce a stable branch where we 
 only
 pull in non-breaking changes from master.
unstable != dev
Nov 28 2012
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Nov 29, 2012 at 02:49:43AM +0100, deadalnix wrote:
 On Thursday, 29 November 2012 at 01:30:42 UTC, H. S. Teoh wrote:
Huh? Who said anything about master being stable? Obviously master is
unstable by definition, since that's where the development work is
being done. The whole point was to introduce a stable branch where we
only pull in non-breaking changes from master.
unstable != dev
OK, but dev implies unstable. T -- There are 10 kinds of people in the world: those who can count in binary, and those who can't.
Nov 28 2012
prev sibling parent Thomas Koch <thomas koch.ro> writes:
H. S. Teoh wrote:
 Huh? Who said anything about master being stable? Obviously master is
 unstable by definition, since that's where the development work is being
 done. The whole point was to introduce a stable branch where we only
 pull in non-breaking changes from master. 
I think you mean "cherry-pick non-breaking changes from master". Cherry- Picking in Git means to just apply one commit from a given branch to another one instead of merging the complete branch. Thomas Koch
Nov 29 2012
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-11-29 02:08, H. S. Teoh wrote:

 I think ultimately, as Walter has said, nothing is going to change
 unless somebody steps up to the plate and champions the effort to make a
 stable branch. Writing up proposals, specs, and other docs are good in
 theory, but won't accomplish a thing if nobody actually *does* anything
 about it. I think 1100110 has stepped up to make a stable branch; let's
 work with him to make it actually happen.
I don't think that is enough. We need to get some assurance that if someone creates a stable branch/fork there should be releases based on this branch on dlang.org and the site should be pointing users to the stable version first and foremost. -- /Jacob Carlborg
Nov 28 2012
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Nov 29, 2012 at 08:54:43AM +0100, Jacob Carlborg wrote:
 On 2012-11-29 02:08, H. S. Teoh wrote:
 
I think ultimately, as Walter has said, nothing is going to change
unless somebody steps up to the plate and champions the effort to
make a stable branch. Writing up proposals, specs, and other docs are
good in theory, but won't accomplish a thing if nobody actually
*does* anything about it. I think 1100110 has stepped up to make a
stable branch; let's work with him to make it actually happen.
I don't think that is enough. We need to get some assurance that if someone creates a stable branch/fork there should be releases based on this branch on dlang.org and the site should be pointing users to the stable version first and foremost.
[...] Didn't Walter already say that if somebody steps up to do it, he would endorse it? T -- "640K ought to be enough" -- Bill G., 1984. "The Internet is not a primary goal for PC usage" -- Bill G., 1995. "Linux has no impact on Microsoft's strategy" -- Bill G., 1999.
Nov 29 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-11-29 17:12, H. S. Teoh wrote:

 Didn't Walter already say that if somebody steps up to do it, he would
 endorse it?
Not what I've seen. At least not something more in those words. -- /Jacob Carlborg
Nov 29 2012
parent reply "Rob T" <rob ucora.com> writes:
On Thursday, 29 November 2012 at 20:54:33 UTC, Jacob Carlborg 
wrote:
 On 2012-11-29 17:12, H. S. Teoh wrote:

 Didn't Walter already say that if somebody steps up to do it, 
 he would
 endorse it?
Not what I've seen. At least not something more in those words.
What's needed is a core team of decision makers who have real decision making abilities. There's a reason why dictatorships usually perform poorly relative to other more advanced systems of decision making. --rt
Nov 29 2012
parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, November 29, 2012 22:01:46 Rob T wrote:
 On Thursday, 29 November 2012 at 20:54:33 UTC, Jacob Carlborg
 
 wrote:
 On 2012-11-29 17:12, H. S. Teoh wrote:
 Didn't Walter already say that if somebody steps up to do it,
 he would
 endorse it?
Not what I've seen. At least not something more in those words.
What's needed is a core team of decision makers who have real decision making abilities. There's a reason why dictatorships usually perform poorly relative to other more advanced systems of decision making.
The benevolent dictator model is quite common in open source software development. There needs to be a team to support that if you want to really be a team project rather than one person's pet project, and it's not like the dictator decides everything, but having one person with the final say can be very beneficial. http://en.wikipedia.org/wiki/Benevolent_Dictator_For_Life But as it stands, there's plenty of decision making that goes on outside of Walter with regards to Phobos. In fact, he's not involved with Phobos much at all at this point. It's really just the language and the compiler over which Walter exercises that level of control. - Jonathan M Davis
Nov 29 2012
parent reply "Rob T" <rob ucora.com> writes:
On Thursday, 29 November 2012 at 22:12:08 UTC, Jonathan M Davis 
wrote:
 The benevolent dictator model is quite common in open source 
 software
 development. There needs to be a team to support that if you 
 want to really be
 a team project rather than one person's pet project, and it's 
 not like the
 dictator decides everything, but having one person with the 
 final say can be
 very beneficial.
Fair enough, I can accept that, and will even agree with it.
 http://en.wikipedia.org/wiki/Benevolent_Dictator_For_Life

 But as it stands, there's plenty of decision making that goes 
 on outside of
 Walter with regards to Phobos. In fact, he's not involved with 
 Phobos much at
 all at this point. It's really just the language and the 
 compiler over which
 Walter exercises that level of control.

 - Jonathan M Davis
In my view, the biggest problem that I see is how the project development is structured, so if anything is to change for the better in a significant way, it will be with changing the development process, and that should have no effect on Walter's status as a benevolent dictator (something which I have no reason at all to question), but it should create a sense of stability and a much smoother release process for everyone concerned. Seriously, how many years has the D community been operating in this way, 10 or more? There's not a heck of a lot here to debate other than to simply start the process of switching over to a more stable and efficient development process. --rt
Nov 29 2012
next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 11/29/12, Rob T <rob ucora.com> wrote:
 Seriously, how many years has the D community been operating in
 this way, 10 or more?
Not really, the D team switched to Git only recently (maybe 1+ years now?). Imo what's really lacking is (wo)manpower, not the process (which can of course always be improved).
Nov 29 2012
parent reply "Rob T" <rob ucora.com> writes:
On Friday, 30 November 2012 at 00:21:17 UTC, Andrej Mitrovic 
wrote:
 On 11/29/12, Rob T <rob ucora.com> wrote:
 Seriously, how many years has the D community been operating in
 this way, 10 or more?
Not really, the D team switched to Git only recently (maybe 1+ years now?).
If the problem here is just some growing pains to deal with, then we're in a good position to move forward.
 Imo what's really lacking is (wo)manpower, not the process
 (which can of course always be improved).
If we're lacking in manpower, then how do we attract a larger force of talented and dedicated volunteers? My answer is that an improved process that's done right will allow us to get more quality work done faster with the same work force, and that in turns helps to motivate new people to sign up and stay signed up. So what's primarily lacking is a good process, what follows will be an improved work force, and following that a growing work force. Anyone have a better answer? --rt
Nov 29 2012
parent 1100110 <0b1100110 gmail.com> writes:
On 11/29/2012 11:44 PM, Rob T wrote:
 On Friday, 30 November 2012 at 00:21:17 UTC, Andrej Mitrovic wrote:
 On 11/29/12, Rob T <rob ucora.com> wrote:
 Seriously, how many years has the D community been operating in
 this way, 10 or more?
Not really, the D team switched to Git only recently (maybe 1+ years now?).
If the problem here is just some growing pains to deal with, then we're in a good position to move forward.
 Imo what's really lacking is (wo)manpower, not the process
 (which can of course always be improved).
If we're lacking in manpower, then how do we attract a larger force of talented and dedicated volunteers? My answer is that an improved process that's done right will allow us to get more quality work done faster with the same work force, and that in turns helps to motivate new people to sign up and stay signed up. So what's primarily lacking is a good process, what follows will be an improved work force, and following that a growing work force. Anyone have a better answer? --rt
Yes! That's exactly how I feel.
Nov 29 2012
prev sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Friday, November 30, 2012 01:21:06 Andrej Mitrovic wrote:
 On 11/29/12, Rob T <rob ucora.com> wrote:
 Seriously, how many years has the D community been operating in
 this way, 10 or more?
Not really, the D team switched to Git only recently (maybe 1+ years now?). Imo what's really lacking is (wo)manpower, not the process (which can of course always be improved).
And D2 has only been around for about 5 years. Things have change a lot over time - particularly with the introduction of github. We have _far_ more community involvement than we used to. But the process definitely still needs improvement (e.g. we need to actually take advantage of git's branching capabilities). But historically, the main problem has always been a lack of manpower, and that's still an issue. It's just not as big an issue as it used to be. If anything the problems with the current process stem from moving to github and getting more contributors. A lot of how the process has worked worked just fine with svn and fewer people. But the project is growing and we need to adjust. - Jonathan M Davis
Nov 29 2012
prev sibling next sibling parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 11/28/2012 08:02 PM, 1100110 wrote:
 A new module in Phobos is highly unlikely to break anything, So I would assume
 that this would count as a simple bug fix and be merged.
I don't really see that. Yes, new functionality _per se_ is not going to break anything, but its implementation may be affected by breaking changes to D. So, if you want to bring something new to Phobos, you may have to write 2 variants (for stable and dev) or else put up with your new functionality being excluded from stable until the breaking changes to D are merged in.
Nov 29 2012
parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
11/29/2012 11:08 PM, Joseph Rushton Wakeling пишет:
 On 11/28/2012 08:02 PM, 1100110 wrote:
 A new module in Phobos is highly unlikely to break anything, So I
 would assume
 that this would count as a simple bug fix and be merged.
I don't really see that. Yes, new functionality _per se_ is not going to break anything, but its implementation may be affected by breaking changes to D. So, if you want to bring something new to Phobos, you may have to write 2 variants (for stable and dev) or else put up with your new functionality being excluded from stable until the breaking changes to D are merged in.
I concur. Phobos is unstable in so much as compiler changes. So is true for the other libraries. It would be my understanding that all project should rather use stable branch. Only those willing to try things out should use unstable and/or maintain 2 branches. But then unstable might not get enough test coverage. -- Dmitry Olshansky
Nov 29 2012
prev sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Nov 29, 2012 at 08:08:08PM +0100, Joseph Rushton Wakeling wrote:
 On 11/28/2012 08:02 PM, 1100110 wrote:
A new module in Phobos is highly unlikely to break anything, So I
would assume that this would count as a simple bug fix and be merged.
I don't really see that. Yes, new functionality _per se_ is not going to break anything, but its implementation may be affected by breaking changes to D. So, if you want to bring something new to Phobos, you may have to write 2 variants (for stable and dev) or else put up with your new functionality being excluded from stable until the breaking changes to D are merged in.
Isn't this only necessary if the new feature depends on said breaking changes? If not, it can be safely merged in. If it's a trivial change like a syntax change, the stable maintainer can simply fix it by hand and merge it in anyway. The way I see it, is that after each release cycle, master is frozen for beta testing, bugs are fixed, then master becomes the new stable (say, by making a stable branch off the current master), then development continues on master (apart from the new stable). Then there's no need to reconcile any tweaks previously made to the previous stable branch, since those will be distinct from the new stable. If we do it this way, we can have actual, maintainable release branches. For example: (This is a hypothetical timeline:) 2013 Jan: master is deemed stable enough to be released, so we make a new stable branch, call it stable-2.061. New development work continues on master. 2013 Mar: new features are added to master. Stable maintainer decides those changes are non-breaking and safe to merge in, so he cherry-picks the changes and puts them into stable-2.061. 2013 Apr: breaking changes are made to master. Stable maintainer decides *not* to pull them into stable-2.061. 2014 Jun: master is deemed almost ready for next release. Code is frozen and extensive testing is done. Stable maintainer cherry-picks most important fixes and backports them to stable-2.061. 2014 Jul: master is deemed releasable. Stable maintainer makes a new branch from master, stable-2.062. New development continues on master. The previous stable branch stable-2.061, is retired, or put in maintenance mode (no longer actively maintained, but if there's a critical fix in master that people are clamoring for, somebody can cherry-pick those and put them in -- after making sure it's non-breaking, of course). etc.. The important thing to note here is that Walter & co. only ever works on master. Whoever maintains the stable branches makes the decisions on what to cherry-pick from master to put in the stable branch(es). (It doesn't have to be exclusive, of course, ideally he would garner some consensus on what should be included, but the point is that the core developers shouldn't even have to worry about what goes into the stable branches, they just work on master.) T -- MACINTOSH: Most Applications Crash, If Not, The Operating System Hangs
Nov 29 2012
parent reply "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 29 November 2012 at 19:30:00 UTC, H. S. Teoh wrote:
 Isn't this only necessary if the new feature depends on said 
 breaking
 changes? If not, it can be safely merged in. If it's a trivial 
 change
 like a syntax change, the stable maintainer can simply fix it 
 by hand
 and merge it in anyway.
New code means new bugs. This is why most project use the 3 numbers version. Eventually, if you add a new module to phobos, people use it, and even if you don't you ends up using it indirectly and you get the bugs.
Nov 29 2012
parent reply "Rob T" <rob ucora.com> writes:
On Thursday, 29 November 2012 at 19:53:13 UTC, deadalnix wrote:
 On Thursday, 29 November 2012 at 19:30:00 UTC, H. S. Teoh wrote:
 Isn't this only necessary if the new feature depends on said 
 breaking
 changes? If not, it can be safely merged in. If it's a trivial 
 change
 like a syntax change, the stable maintainer can simply fix it 
 by hand
 and merge it in anyway.
New code means new bugs. This is why most project use the 3 numbers version. Eventually, if you add a new module to phobos, people use it, and even if you don't you ends up using it indirectly and you get the bugs.
The 3 number system is fine grained enough to do what we probably want. If we use 3 version numbers like this: major.minor.revision, then Incrementing "major" indicates a major release with breaking changes incorporated and/or new features added. Incrementing "minor" indicates no breaking changes, no new features, but possibly new bugs were introduced due to the the changes that were made. Incrementing "revision" indicates a bug fix only release. We should also have 3 branches in principle, each corresponding to the 3 version numbers. One for stable, which receives only revision updates after major.minor is frozen, another for pre-stable and also for the "stable candidate" which frozen from new features, but uses same branch, and a 3rd for unstable, which eventually moves to pre-stable branch. This is more or less how Debian seems to do it. --rt
Nov 29 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-11-29 21:36, Rob T wrote:
 On Thursday, 29 November 2012 at 19:53:13 UTC, deadalnix wrote:
 On Thursday, 29 November 2012 at 19:30:00 UTC, H. S. Teoh wrote:
 Isn't this only necessary if the new feature depends on said breaking
 changes? If not, it can be safely merged in. If it's a trivial change
 like a syntax change, the stable maintainer can simply fix it by hand
 and merge it in anyway.
New code means new bugs. This is why most project use the 3 numbers version. Eventually, if you add a new module to phobos, people use it, and even if you don't you ends up using it indirectly and you get the bugs.
The 3 number system is fine grained enough to do what we probably want. If we use 3 version numbers like this: major.minor.revision, then Incrementing "major" indicates a major release with breaking changes incorporated and/or new features added. Incrementing "minor" indicates no breaking changes, no new features, but possibly new bugs were introduced due to the the changes that were made.
That's not what I've heard. Minor could be new features, as long as they don't break anything. But that might be more for libraries, i.e. adding a new function. -- /Jacob Carlborg
Nov 29 2012
parent reply "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 29 November 2012 at 21:19:02 UTC, Jacob Carlborg 
wrote:
 That's not what I've heard. Minor could be new features, as 
 long as they don't break anything. But that might be more for 
 libraries, i.e. adding a new function.
Exactly.
Nov 29 2012
parent "Rob T" <rob ucora.com> writes:
On Thursday, 29 November 2012 at 21:36:46 UTC, deadalnix wrote:
 On Thursday, 29 November 2012 at 21:19:02 UTC, Jacob Carlborg 
 wrote:
 That's not what I've heard. Minor could be new features, as 
 long as they don't break anything. But that might be more for 
 libraries, i.e. adding a new function.
Exactly.
Yes, after posting I thought that part was perhaps debatable. The real challenge is how to implement something like this in a reasonable time frame. Who has the means to make it so? --rt
Nov 29 2012
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-11-28 02:38, SiegeLord wrote:
 Another DMD alpha, another set of previously valid code that no longer
 compiles. With 2.060 it was the TypeInfo constness changes in druntime,
 with 2.061 it is the dissalowance of rebindability of the this pointer.
 The latter did make it into the spec half a year ago, but recently it
 was actually dissallowed in the beta. Unlike many other features of the
 sort (e.g. octal literals) there is no warning or deprecation errors...
 code that use to compile simply does not anymore.

 In this last case, in principle, we were lucky... the spec was changed.
 What about things like this: http://dlang.org/attribute.html#inout . Are
 those undocumented features liable to change at any time? What warning
 will there be when somebody decides to submit an inout bug and somebody
 else fixes it in a way that breaks existing code?

 D1 is scheduled to be discontinued in a month, and every new version of
 DMD keeps changing D2 in code breaking ways (or worse, with backwards
 incompatible spec changes). I think that unless people responsible for
 these things get their act together and stabilize D2 against these
 issues, D1 support should be extended until that happens.
Welcome do D. -- /Jacob Carlborg
Nov 27 2012
prev sibling next sibling parent reply "Dejan Lekic" <dejan.lekic gmail.com> writes:
On Wednesday, 28 November 2012 at 01:38:38 UTC, SiegeLord wrote:
 Another DMD alpha, another set of previously valid code that no 
 longer compiles. With 2.060 it was the TypeInfo constness 
 changes in druntime, with 2.061 it is the dissalowance of 
 rebindability of the this pointer. The latter did make it into 
 the spec half a year ago, but recently it was actually 
 dissallowed in the beta. Unlike many other features of the sort 
 (e.g. octal literals) there is no warning or deprecation 
 errors... code that use to compile simply does not anymore.

 In this last case, in principle, we were lucky... the spec was 
 changed. What about things like this: 
 http://dlang.org/attribute.html#inout . Are those undocumented 
 features liable to change at any time? What warning will there 
 be when somebody decides to submit an inout bug and somebody 
 else fixes it in a way that breaks existing code?

 D1 is scheduled to be discontinued in a month, and every new 
 version of DMD keeps changing D2 in code breaking ways (or 
 worse, with backwards incompatible spec changes). I think that 
 unless people responsible for these things get their act 
 together and stabilize D2 against these issues, D1 support 
 should be extended until that happens.
Now you understand why I stick to Java at work, and use D only for non mission-critical (small) projects. If I know that the project is going to have large code-base I *do not* use D (by D I always mean D2). However, If I *had to* use D for a large-scale project I would do the following: 1) Make my own fork of DMD, Druntime and Phobos, and maintain them myself. Ie. merge only changes from the upstream that do not break my own project. 2) Use these forked projects to build my project. 3) Periodically, when time permits, I "jump" to the latest release of DMD, Druntime and Phobos. Naturally that would be a big job, to fix my broken projects code. But as I said, I have reserved a lot of time for this so I am fine with this. This is how it is done in real world mostly. I know I did it in the past. I used an experimental branch of a certain C++ GUI toolkit in a large project. I did exactly what I explained above, and it was all right! :)
Nov 28 2012
parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Wednesday, 28 November 2012 at 08:51:02 UTC, Dejan Lekic wrote:
 On Wednesday, 28 November 2012 at 01:38:38 UTC, SiegeLord wrote:
 Another DMD alpha, another set of previously valid code that 
 no longer compiles. With 2.060 it was the TypeInfo constness 
 changes in druntime, with 2.061 it is the dissalowance of 
 rebindability of the this pointer. The latter did make it into 
 the spec half a year ago, but recently it was actually 
 dissallowed in the beta. Unlike many other features of the 
 sort (e.g. octal literals) there is no warning or deprecation 
 errors... code that use to compile simply does not anymore.

 In this last case, in principle, we were lucky... the spec was 
 changed. What about things like this: 
 http://dlang.org/attribute.html#inout . Are those undocumented 
 features liable to change at any time? What warning will there 
 be when somebody decides to submit an inout bug and somebody 
 else fixes it in a way that breaks existing code?

 D1 is scheduled to be discontinued in a month, and every new 
 version of DMD keeps changing D2 in code breaking ways (or 
 worse, with backwards incompatible spec changes). I think that 
 unless people responsible for these things get their act 
 together and stabilize D2 against these issues, D1 support 
 should be extended until that happens.
Now you understand why I stick to Java at work, and use D only for non mission-critical (small) projects. If I know that the project is going to have large code-base I *do not* use D (by D I always mean D2). However, If I *had to* use D for a large-scale project I would do the following: 1) Make my own fork of DMD, Druntime and Phobos, and maintain them myself. Ie. merge only changes from the upstream that do not break my own project. 2) Use these forked projects to build my project. 3) Periodically, when time permits, I "jump" to the latest release of DMD, Druntime and Phobos. Naturally that would be a big job, to fix my broken projects code. But as I said, I have reserved a lot of time for this so I am fine with this. This is how it is done in real world mostly. I know I did it in the past. I used an experimental branch of a certain C++ GUI toolkit in a large project. I did exactly what I explained above, and it was all right! :)
I fully agree. This only works however, if the overhead is not too much and management is ok with it. -- Paulo
Nov 28 2012
prev sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 11/28/12, SiegeLord <none none.com> wrote:
 with 2.061 it is the dissalowance of rebindability
 of the this pointer.
We can still revert this pull since 2.061 was not officially released yet. I think we've simply missed Walter's comment which you linked to: http://d.puremagic.com/issues/show_bug.cgi?id=780#c3
Nov 28 2012
parent Walter Bright <newshound2 digitalmars.com> writes:
On 11/28/2012 10:18 PM, Andrej Mitrovic wrote:
 On 11/28/12, SiegeLord <none none.com> wrote:
 with 2.061 it is the dissalowance of rebindability
 of the this pointer.
We can still revert this pull since 2.061 was not officially released yet. I think we've simply missed Walter's comment which you linked to: http://d.puremagic.com/issues/show_bug.cgi?id=780#c3
Yeah, it seems that the warning & deprecation stages were skipped. That was a mistake.
Nov 28 2012