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?

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

On 11/28/12 11:32 AM, Jonathan M Davis wrote:
> On Wednesday, November 28, 2012 09:33:13 Andrei Alexandrescu wrote:
>> The problem with the above is the count of "I", which is too large. We
>> need to switch from "I" to "we" so we can scale up.
>
> And opening up dmd to more committers was a good start, but the overall
> development process needs to go that way as well (as the situation with user-
> defined attributes helps illustrate).
>
> - Jonathan M Davis

One good step toward that would be a combination of (a) a good wiki page and (b) a good set of git macros - that implements a simple and effective github-based process.


Andrei

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

On Wednesday, November 28, 2012 07:44:39 Andrei Alexandrescu wrote:
> On 11/28/12 3:01 AM, Jacob Carlborg wrote:
> > TDPL was release way, way too soon. It was written before many of the features were even implemented. Then at a later stage "Whoops, this apparently doesn't work, we need to break TDPL".
> 
> I disagree. Aside from a few details, the language described by TDPL is implementable. The problem becomes when TDPL gets in competition with incorrect code that currently compiles and runs although it shouldn't.

That's mostly true, but there are some features which have required further ironing out even if TDPL is mostly correct about them still (e.g. pure and shared), and some features _still_ aren't properly implemented (e.g. synchronized and alias this).

I'm not about to say that TDPL was released too early (it's been a _great_ resource and has undoubtedly helped the community grow), but at the same time, it doesn't quite represent what the language actually is, and we're slow at catching up with it. So, in that sense, if TDPL is meant to be a definitive resource, it would have been nice to have the implementation be closer to where TDPL is before having released it

However, a _big_ benefit from having not delayed its release was that that a lot of stuff stopped changing after that. We stopped making huge, incompatible changes from release to release of the compiler. We didn't stop making breaking changes, but for the most part, we stopped trying to design the language and instead have focused on finishing implementing it. All of the design work that has happened since then has either fixed a pressing problem caused by the current design (e.g. weak purity) or introduced new, compatible features (e.g. SIMD). We're no longer doing stuff like changing how operator overloading works just because we came up with a cooler, better way to do it.

- Jonathan M Davis

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

A monthly 'beta' with a twice yearly stable release sounds good to me.

It would be even better if we had a tool that attempted to automatically fix minor breaking changes. (for the stable of course.)

To use an example from another thread, func(auto const ref var) doesn't work, but func(auto ref var) does.  It would be relatively trivial to strip the const if that was one of the breaking changes.

On Wed, Nov 28, 2012 at 01:43:53PM +0100, Jacob Carlborg wrote:
> On 2012-11-28 12:48, Manu wrote:
> >I think the best approach is one that others have suggested, 2 branches, 'stable' which is maintained for 6-12 months, and only receives non-breaking fixes after they've been tested for a while, and 'dev', which users accept may receive breaking changes at any time. Those users will be happy to adapt their code as the language moves forward, as I am.
> 
> I completely agree, it's not rocket science.
[...]

+1.

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

And here's a further suggestion: somebody else other than Walter should maintain the 'stable' branch, so that Walter can continue working on bleeding-edge stuff, without having to split his time with maintaining yet another branch. Preferably have a team of 2 or 3 who track the 'unstable' git commits, and decide which ones are safe to pull into the 'stable' branch.


T

-- 
"I'm not childish; I'm just in touch with the child within!" - RL

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!

On Wednesday, November 28, 2012 16:49:40 ixid wrote:
> On Wednesday, 28 November 2012 at 15:32:47 UTC, bearophile wrote:
> > I also think it's a bad idea to create a "D3", at the moment.
> 
> I think it's a bad idea to create a D3 ever. The language must not remain an eternal language tinkering project, it must be committed to to create a long-lasting and stable platform that settles down, otherwise it will remain forever peripheral. Are there really areas which are so terrible and unfixable in D2 that a D3 would be required?

Every language ends up with stuff that's unfixable without breaking backwards compatibility, and if those changes are large enough, you need a new version of the language (or a new language) which is not intended to be compatibile with the previous one (as opposed to trying to transition in the breakage - which doesn't work at all if you refuse to break backwards compatibility at all like languages such as C++ typically do).

Other languages have created new versions which were not backwards compatible (e.g. python 3). But it's not the sort of thing that you do often, and it's not the sort of thing that you do lightly. Certainly, it's not something that we should be doing any time soon - or even _think_ about doing any time soon. It's years off at the earliest. And whether it makes any sense at that point needs to be examined in detail then. We can't possibly know what the situation will be at that point.

So, I'm not at all prepared to say that there should never be a D3, but I don't think that it's something that's even vaguely on the table at this point. It's an issue to be discussed years from now after D2 has long since become stable and is heavily used.

- Jonathan M Davis

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

A new module in Phobos is highly unlikely to break anything, So I would assume that this would count as a simple bug fix and be merged.