digitalmars.D - Breaking D2 language/spec changes with D1 being discontinued in a
- SiegeLord (20/20) Nov 27 2012 Another DMD alpha, another set of previously valid code that no
- bearophile (7/10) Nov 27 2012 It will take some more years to see D2 "stabilized" like that.
- SiegeLord (18/22) Nov 27 2012 With that kind of attitude D2 will never stabilize.
- Robert (41/47) Nov 27 2012 I tend to disagree a bit. First D is a very, very powerful language
- deadalnix (7/21) Nov 28 2012 Actually, this is true that D have little resources, and the work
- Jacob Carlborg (11/22) Nov 28 2012 TDPL was release way, way too soon. It was written before many of the
- SiegeLord (28/30) Nov 28 2012 After years of using D1 and D2, I've lowered my expectations
- Max Samukha (14/44) Nov 28 2012 I have a different concession. I come here on a regular basis to
- Walter Bright (4/10) Nov 28 2012 That issue is marked as "normal", not critical. You can raise it to
- Max Samukha (6/19) Nov 28 2012 From my and other people's experience, setting bug severity,
- Walter Bright (2/5) Nov 28 2012 Thank you.
- Walter Bright (9/16) Nov 28 2012 On the other hand, many people were unhappy with my position of "no
- Jacob Carlborg (8/14) Nov 28 2012 Please, please try and understand. It's not breaking changes in it self
- Walter Bright (15/18) Nov 28 2012 The trouble with that is now I'd be maintaining 3 versions of the
- Maxim Fomin (11/32) Nov 28 2012 Thanks for writing this: it explains something regarding slowness
- Walter Bright (16/23) Nov 28 2012 Since D is a volunteer organization, my assigning tasks to people tends
- Jacob Carlborg (5/9) Nov 28 2012 You also need to promise that you will put up the releases at dlang.org
- Jacob Carlborg (11/25) Nov 28 2012 I don't know if there would be a point of having D1 if something like
- Andrei Alexandrescu (4/22) Nov 28 2012 The problem with the above is the count of "I", which is too large. We
- Jonathan M Davis (5/7) Nov 28 2012 And opening up dmd to more committers was a good start, but the overall
- Andrei Alexandrescu (5/12) Nov 28 2012 One good step toward that would be a combination of (a) a good wiki page...
- Jacob Carlborg (5/8) Nov 28 2012 git macros are only good if you know what you're doing. If you don't and...
- Walter Bright (2/4) Nov 28 2012 I understand this, see my other reply here about champions.
- bearophile (35/38) Nov 28 2012 I am OK with such ideas. Below there are some musings.
- ixid (7/8) Nov 28 2012 I think it's a bad idea to create a D3 ever. The language must
- Jonathan M Davis (19/28) Nov 28 2012 Every language ends up with stuff that's unfixable without breaking back...
- Walter Bright (1/1) Nov 28 2012 Right on, Jonathan.
- 1100110 (7/42) Nov 28 2012 A monthly 'beta' with a twice yearly stable release sounds good to me.
- 1100110 (2/37) Nov 29 2012
- Jonathan M Davis (7/10) Nov 28 2012 Well, then we're about to reach the point when it's ripe to do that, bec...
- Jacob Carlborg (5/10) Nov 28 2012 We said the same thing before the 2.060 release. And most likely before
- 1100110 (4/16) Nov 28 2012 Soo.... Theoretically Speaking.
- Jacob Carlborg (4/7) Nov 28 2012 Yes, theoretically speaking. Unfortunately I don't have the time to do t...
- Iain Buclaw (5/13) Nov 28 2012 So the plans of a stable releases branch never came into fruition?
- 1100110 (4/18) Nov 28 2012 https://github.com/D-Programming-Language-Stable/dmd
- Walter Bright (4/7) Nov 28 2012 I think it's great that you're stepping up.
- 1100110 (12/22) Nov 28 2012 I don't have commit privs on the main repo. =P
- 1100110 (9/19) Nov 28 2012 Oh! while I have your attention... Looking at the makefiles for DMD,
- H. S. Teoh (10/20) Nov 28 2012 Rarely known fact: you can invoke make like this:
- 1100110 (7/25) Nov 28 2012 I know, I just have a bad habit of digging through makefiles and such
- Walter Bright (2/7) Nov 28 2012 Not only is it similar, it's exactly the same.
- H. S. Teoh (8/19) Nov 28 2012 [...]
- Walter Bright (6/10) Nov 28 2012 Something has to be the default, and that dates back to when D was only
- Jacob Carlborg (4/6) Nov 28 2012 How about defaulting to the architecture one is building on?
- Jonathan M Davis (5/10) Nov 28 2012 I believe that that's what most applications do when you build them - at...
- 1100110 (2/12) Nov 29 2012 Simply leaving MODEL= blank does just that.
- Manu (3/28) Nov 29 2012 Perhaps this is a really stupid question...
- Jacob Carlborg (4/5) Nov 28 2012 Not that I've heard of.
- 1100110 (2/16) Nov 28 2012 Would you be interested in helping?
- cal (3/8) Nov 28 2012 Wasn't this the same idea?
- Jacob Carlborg (7/8) Nov 28 2012 Yes, but as I said, unfortunately I don't have the time. I also don't
- Iain Buclaw (6/30) Nov 29 2012 I would support it if were made available. To do double work is
- Walter Bright (10/15) Nov 28 2012 My thoughts, too.
- Danni Coy (8/28) Nov 29 2012 Holy crap I had no idea that this conference even existed. It turns out ...
- Walter Bright (3/6) Nov 29 2012 No need, the booze flows freely here! But hey, drop by. It's in the
- Manu (3/35) Nov 29 2012 Yes, and make sure to remind him that it's all your fault! ;)
- John Colvin (36/53) Nov 28 2012 For what it's worth, I agree.
- John Colvin (4/28) Nov 28 2012 sorry, I mean to edit out the bit about D1.5 in Jacob's post, not
- Jacob Carlborg (7/9) Nov 28 2012 Just as with D1 now, it only receives bug fixes. But it would also
- Jonathan M Davis (6/12) Nov 28 2012 I don't know if we want to set up our process to match python's (I don't...
- Andrei Alexandrescu (5/8) Nov 28 2012 I disagree. Aside from a few details, the language described by TDPL is
- Jonathan M Davis (21/29) Nov 28 2012 That's mostly true, but there are some features which have required furt...
- bearophile (22/23) Nov 28 2012 Currently in D there are unfinished parts like vector operations
- Paulo Pinto (8/18) Nov 27 2012 The problem we have with this situation is that language users
- Manu (25/43) Nov 28 2012 If D stabilised on exactly the feature set it offers right now (or even ...
- Jacob Carlborg (4/9) Nov 28 2012 I completely agree, it's not rocket science.
- H. S. Teoh (13/22) Nov 28 2012 [...]
- Jacob Carlborg (6/14) Nov 28 2012 Haven't we already agreed on this, that last time this discussion came
- Joseph Rushton Wakeling (19/30) Nov 28 2012 I'd agree but with one caveat -- how do you handle the case of the stand...
- 1100110 (3/45) Nov 28 2012 A new module in Phobos is highly unlikely to break anything, So I would
- eskimo (30/35) Nov 28 2012 Well either you want stable or bleeding edge. New features need to
- bearophile (8/18) Nov 28 2012 Maybe there are alternative ways to do this.
- H. S. Teoh (12/27) Nov 28 2012 [...]
- deadalnix (4/15) Nov 28 2012 I'm sorry, but I don't see how a champion can prevent stuff to be
- Jonathan M Davis (8/24) Nov 28 2012 Since master will almost certainly be the development branch, I don't se...
- deadalnix (14/26) Nov 28 2012 In this case, all bug fixes are mixed with new feature and then
- Manu (5/31) Nov 29 2012 Why don't you document precisely what branches you think should exist, a...
- foobar (29/80) Nov 29 2012 Manu:
- eskimo (5/9) Nov 29 2012 That is pretty much what I had in mind, but more concrete thought
- eskimo (5/17) Nov 29 2012 We would then simply do regular dev releases of the development branch
- Jacob Carlborg (4/26) Nov 29 2012 So true.
- H. S. Teoh (8/20) Nov 28 2012 Huh? Who said anything about master being stable? Obviously master is
- deadalnix (2/9) Nov 28 2012 unstable != dev
- H. S. Teoh (5/13) Nov 28 2012 OK, but dev implies unstable.
- Thomas Koch (5/9) Nov 29 2012 I think you mean "cherry-pick non-breaking changes from master". Cherry-
- Jacob Carlborg (7/13) Nov 28 2012 I don't think that is enough. We need to get some assurance that if
- H. S. Teoh (7/20) Nov 29 2012 [...]
- Jacob Carlborg (4/6) Nov 29 2012 Not what I've seen. At least not something more in those words.
- Rob T (7/12) Nov 29 2012 What's needed is a core team of decision makers who have real
- Jonathan M Davis (12/26) Nov 29 2012 The benevolent dictator model is quite common in open source software
- Rob T (16/34) Nov 29 2012 Fair enough, I can accept that, and will even agree with it.
- Andrej Mitrovic (4/6) Nov 29 2012 Not really, the D team switched to Git only recently (maybe 1+ years
- Rob T (14/22) Nov 29 2012 If the problem here is just some growing pains to deal with, then
- 1100110 (2/22) Nov 29 2012 Yes! That's exactly how I feel.
- Jonathan M Davis (13/20) Nov 29 2012 And D2 has only been around for about 5 years. Things have change a lot ...
- Joseph Rushton Wakeling (6/8) Nov 29 2012 I don't really see that. Yes, new functionality _per se_ is not going t...
- Dmitry Olshansky (8/18) Nov 29 2012 I concur. Phobos is unstable in so much as compiler changes. So is true
- H. S. Teoh (43/53) Nov 29 2012 Isn't this only necessary if the new feature depends on said breaking
- deadalnix (5/12) Nov 29 2012 New code means new bugs. This is why most project use the 3
- Rob T (18/31) Nov 29 2012 The 3 number system is fine grained enough to do what we probably
- Jacob Carlborg (6/24) Nov 29 2012 That's not what I've heard. Minor could be new features, as long as they...
- Jacob Carlborg (4/21) Nov 27 2012 Welcome do D.
- Dejan Lekic (19/39) Nov 28 2012 Now you understand why I stick to Java at work, and use D only
- Paulo Pinto (6/47) Nov 28 2012 I fully agree.
- Andrej Mitrovic (4/6) Nov 28 2012 We can still revert this pull since 2.061 was not officially released
- Walter Bright (3/9) Nov 28 2012 Yeah, it seems that the warning & deprecation stages were skipped. That
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
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
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
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
On Wednesday, 28 November 2012 at 07:52:54 UTC, Robert wrote: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.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.
Nov 28 2012
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 withdeliberate 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
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
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 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.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
On 11/28/2012 11:34 P I come here on a regular basis to see ifthe 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
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 ifFrom 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.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
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
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
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
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
On Wednesday, 28 November 2012 at 13:36:01 UTC, Walter Bright wrote:On 11/29/2012 12:15 AM, Jacob Carlborg wrote: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.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
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
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
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
On 11/28/12 8:35 AM, Walter Bright wrote:On 11/29/2012 12:15 AM, Jacob Carlborg 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. AndreiMany 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
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
On 11/28/12 11:32 AM, Jonathan M Davis wrote:On Wednesday, November 28, 2012 09:33:13 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. AndreiThe 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
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
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
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
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
On Wednesday, November 28, 2012 16:49:40 ixid wrote:On Wednesday, 28 November 2012 at 15:32:47 UTC, bearophile wrote: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 DavisI 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
On 11/28/2012 09:32 AM, bearophile wrote:Walter Bright: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.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
On 11/28/2012 09:32 AM, bearophile wrote:Walter Bright:Added to my things first list.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 29 2012
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
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
On 11/28/2012 01:30 PM, Jacob Carlborg wrote:On 2012-11-28 17:31, Jonathan M Davis 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?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.
Nov 28 2012
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
On 28 November 2012 20:15, Jacob Carlborg <doob me.com> wrote:On 2012-11-28 20:54, 1100110 wrote:So the plans of a stable releases branch never came into fruition? -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';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
On 11/28/2012 02:48 PM, Iain Buclaw wrote:On 28 November 2012 20:15, Jacob Carlborg<doob me.com> 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.On 2012-11-28 20:54, 1100110 wrote:So the plans of a stable releases branch never came into fruition?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
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
On 11/28/2012 04:40 PM, Walter Bright wrote:On 11/29/2012 8:10 AM, 1100110 wrote: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.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
On 11/28/2012 04:40 PM, Walter Bright wrote:On 11/29/2012 8:10 AM, 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?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
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
On 11/28/2012 06:50 PM, H. S. Teoh wrote:On Wed, Nov 28, 2012 at 06:31:45PM -0600, 1100110 wrote: [...]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.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
Nov 28 2012
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
On Thu, Nov 29, 2012 at 01:11:32PM +1100, Walter Bright wrote:On 11/29/2012 11:50 AM, H. S. Teoh wrote:[...] 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?"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
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
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
On Thursday, November 29, 2012 08:45:53 Jacob Carlborg wrote:On 2012-11-29 01:50, Walter Bright wrote: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 DavisSomething 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?
Nov 28 2012
On 11/29/2012 01:52 AM, Jonathan M Davis wrote:On Thursday, November 29, 2012 08:45:53 Jacob Carlborg wrote:Simply leaving MODEL= blank does just that.On 2012-11-29 01:50, Walter Bright wrote: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 DavisSomething 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?
Nov 29 2012
On 28 November 2012 23:10, 1100110 <0b1100110 gmail.com> wrote:On 11/28/2012 02:48 PM, Iain Buclaw wrote:Perhaps this is a really stupid question... But what's wrong with using branches in the main DMD repo?On 28 November 2012 20:15, Jacob Carlborg<doob me.com> wrote:Phobos and druntime are also in there. Right now I'm just trying to figure out how to organize it.On 2012-11-28 20:54, 1100110 wrote: Soo.... Theoretically Speaking.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>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 29 2012
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
On 11/28/2012 02:48 PM, Iain Buclaw wrote:On 28 November 2012 20:15, Jacob Carlborg<doob me.com> wrote:Would you be interested in helping?On 2012-11-28 20:54, 1100110 wrote:So the plans of a stable releases branch never came into fruition?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
On Wednesday, 28 November 2012 at 21:40:14 UTC, 1100110 wrote:On 11/28/2012 02:48 PM, Iain Buclaw wrote:Wasn't this the same idea? https://github.com/dlang-stableSo the plans of a stable releases branch never came into fruition?Would you be interested in helping?
Nov 28 2012
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
On 28 November 2012 21:40, 1100110 <0b1100110 gmail.com> wrote:On 11/28/2012 02:48 PM, Iain Buclaw wrote: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';On 28 November 2012 20:15, Jacob Carlborg<doob me.com> wrote:Would you be interested in helping?On 2012-11-28 20:54, 1100110 wrote:So the plans of a stable releases branch never came into fruition?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 29 2012
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
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
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
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 beingstable 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.comwrote: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
On Wednesday, 28 November 2012 at 13:15:26 UTC, Jacob Carlborg wrote:On 2012-11-28 13:41, Walter Bright wrote: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.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.
Nov 28 2012
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: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 itOn 2012-11-28 13:41, Walter Bright wrote:For what it's worth, I agree. blah blah blahOn 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.
Nov 28 2012
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 itJust 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
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
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
On Wednesday, November 28, 2012 07:44:39 Andrei Alexandrescu wrote:On 11/28/12 3:01 AM, Jacob Carlborg wrote: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 DavisTDPL 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.
Nov 28 2012
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
On Wednesday, 28 November 2012 at 02:29:12 UTC, bearophile wrote:SiegeLord: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. -- PauloI 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
On 28 November 2012 09:47, Paulo Pinto <pjmlp progtools.org> wrote:On Wednesday, 28 November 2012 at 02:29:12 UTC, bearophile 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. 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 theySiegeLord: I think that unless people responsible for these things get their actThe problem we have with this situation is that language users will just run away to more stable languages.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, bearophileuse, if suggesting D might cause them to risk their job, they won't do it.I feel this personally.
Nov 28 2012
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
On Wed, Nov 28, 2012 at 01:43:53PM +0100, Jacob Carlborg wrote:On 2012-11-28 12:48, Manu 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. T -- "I'm not childish; I'm just in touch with the child within!" - RLI 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.
Nov 28 2012
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
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
On 11/28/2012 12:05 PM, Joseph Rushton Wakeling wrote:On 11/28/2012 12:48 PM, Manu 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.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
On Wed, 2012-11-28 at 13:02 -0600, 1100110 wrote:Given that Phobos is still a moving target with new functionality beingWell 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, Robertadded on a regular basis, it could be a bit of a disappointment tohaveto wait as long as 6 months to see the latest new features.
Nov 28 2012
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
On Thu, Nov 29, 2012 at 01:51:52AM +0100, bearophile wrote:eskimo:[...] 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-FriendlyEven 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.
Nov 28 2012
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
On Thursday, November 29, 2012 02:13:10 deadalnix wrote:On Thursday, 29 November 2012 at 01:06:15 UTC, H. S. Teoh 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. 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 DavisI 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
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
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: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 probablySince 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.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
On Thursday, 29 November 2012 at 09:37:57 UTC, Manu wrote:On 29 November 2012 03:48, deadalnix <deadalnix gmail.com> wrote: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.On Thursday, 29 November 2012 at 01:29:12 UTC, Jonathan M Davis wrote: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 probablySince 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.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
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
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: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.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
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
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: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 WallI 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
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
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: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.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
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
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
On Thu, Nov 29, 2012 at 08:54:43AM +0100, Jacob Carlborg wrote:On 2012-11-29 02:08, H. S. Teoh wrote:[...] 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.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.
Nov 29 2012
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
On Thursday, 29 November 2012 at 20:54:33 UTC, Jacob Carlborg wrote:On 2012-11-29 17:12, H. S. Teoh wrote: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. --rtDidn'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.
Nov 29 2012
On Thursday, November 29, 2012 22:01:46 Rob T wrote:On Thursday, 29 November 2012 at 20:54:33 UTC, Jacob Carlborg 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. 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 DavisOn 2012-11-29 17:12, H. S. Teoh wrote: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.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.
Nov 29 2012
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 DavisIn 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
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
On Friday, 30 November 2012 at 00:21:17 UTC, Andrej Mitrovic wrote:On 11/29/12, Rob T <rob ucora.com> wrote:If the problem here is just some growing pains to deal with, then we're in a good position to move forward.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).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
On 11/29/2012 11:44 PM, Rob T wrote:On Friday, 30 November 2012 at 00:21:17 UTC, Andrej Mitrovic wrote:Yes! That's exactly how I feel.On 11/29/12, Rob T <rob ucora.com> wrote:If the problem here is just some growing pains to deal with, then we're in a good position to move forward.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).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
On Friday, November 30, 2012 01:21:06 Andrej Mitrovic wrote:On 11/29/12, Rob T <rob ucora.com> wrote: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 DavisSeriously, 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
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
11/29/2012 11:08 PM, Joseph Rushton Wakeling пишет:On 11/28/2012 08:02 PM, 1100110 wrote: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 OlshanskyA 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
On Thu, Nov 29, 2012 at 08:08:08PM +0100, Joseph Rushton Wakeling wrote:On 11/28/2012 08:02 PM, 1100110 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. 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 HangsA 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
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
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: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. --rtIsn'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
On 2012-11-29 21:36, Rob T wrote:On Thursday, 29 November 2012 at 19:53:13 UTC, deadalnix 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. -- /Jacob CarlborgOn Thursday, 29 November 2012 at 19:30:00 UTC, H. S. Teoh wrote: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.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
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
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: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? --rtThat'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
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
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
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:I fully agree. This only works however, if the overhead is not too much and management is ok with it. -- PauloAnother 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
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
On 11/28/2012 10:18 PM, Andrej Mitrovic wrote:On 11/28/12, SiegeLord <none none.com> wrote:Yeah, it seems that the warning & deprecation stages were skipped. That was a mistake.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