On 2012-07-16 03:06, Adam Wilson wrote:

> I would like to state that I am all for waiting onr Win64; it's a huge
> project and trying to do this change in the middle of it would be the
> height of stupidity. However, directly after Win64 goes live I move that
> we make the dual branch model the default going forward as it solves too
> many long-standing community complaints to reasonably dismiss.

I see no reason why COFF/Win64 would need to affect the current release (ok it already has, I know). Walter don't need to push his changes upstream. He can either keep them locally or in his own forks (I assume he uses forks).

When the work is finished he can push a new branch upstream and let people try that for a while. Then we can merge that branch when we feel it's stable enough.

-- 
/Jacob Carlborg

On 2012-07-16 02:20, Jonathan M Davis wrote:

> If someone has a better proposal, they should make it (though probably in a
> separate thread - this one's long enough as it is). I think that the basics of
> this proposal are good, and a lot of projects work that way. I just think that
> D needs to be more stable before we worry about having major and minor
> releases or stable and unstable branches.

Wasn't that what you just said two posts up? To have major and minor releases. Major containing new features and minor only bug fixes.

-- 
/Jacob Carlborg

On 2012-07-16 02:36, Jonathan M Davis wrote:

> Arguably, we've been adding too many new features (e.g. new lambda syntax and
> SIMD support), given that we're supposed to be making everything that we
> already  have work properly, but those features haven't been breaking changes,
> and presumably forcing Walter to just fix bugs wouldn't be all that pleasant
> for him. But until we've fully implemented what we have, I think that it's
> just going to slow us down to little benefit to change the release model. Once
> we have, _then_ I'd love to see a release model which promotes major vs minor
> releases and the like, because then we can evolve the language and library as
> appropriate while still maintaining stable releases which programmers can rely
> on for long periods of time without worrying about breaking changes and
> whatnot.

There are lot of other things to do than fixing bugs. For example, the ongoing COFF/Win64 changes. I wouldn't really consider this as a new feature and not really as a bug fix either. Then we have Phobos, ARM and tools to work on as well.

-- 
/Jacob Carlborg

On 2012-07-16 08:00, Walter Bright wrote:

> Supporting Win64 is absolutely critical for the future of D, and the
> sooner we get it, the better. The COFF route is the shortest route to
> doing it, and the most practical for attracting devs, which is why it's
> the way we're going.

Agree.

> 32 bit code is dead on OSX, is dying rapidly on Linux and Windows.

No need in removing that until it cause big maintenance problems.

-- 
/Jacob Carlborg

On 2012-07-16 08:06, Jonathan M Davis wrote:

> Oh, I'm not saying that the feature isn't valuable. I'm just pointing out that
> it's adding something new rather than actually finishing all of the features
> that we're already supposed to have, and in theory, after TDPL's release, we
> were supposed to be avoiding adding new features which we didn't need to make
> all of the existing features work until we'd finished all of the features
> outlined in TDPL. And maybe it _was_ worth adding SIMD support now rather than
> later, but it goes against what we said we were doing.

Yeah, and it did pop up somewhat unexpected. Sure there were a lot of discussion about it but in the middle of the discussions we could see commits adding SIMD support popping up.

-- 
/Jacob Carlborg

On Monday, July 16, 2012 08:48:31 RivenTheMage wrote:
> On Monday, 16 July 2012 at 06:07:21 UTC, Walter Bright wrote:
> > Changing names is minute progress, and is too costly in terms of annoying existing users and breaking their code.
> 
> Cost can be lowered - by introducing (semi-)automatic
> refactoring/upgrade mode.
> 
> dmd -upgrade zzz.d
> 
> Compiler can do renames (clear() -> destroy()), insert
> workarounds (if needed), and so on. Easy, fast, no risk of human
> error.
> 
> Of course, in certain cituations no automatic upgrade is possible...

If we were doing that all the time, then such a tool would be very useful, and it may very well be worth creating such a tool if/when D3 comes around and code needs to be converted, but if we continue to change names often enough that you really need such a tool, then we're screwing up.

Name changes _should_ be rare. We were only doing as many as we were for a while there, because the names in Phobos were quite inconsistent, and almost everyone thought that we'd be better off to fix the names and deal with the breakage then rather than having to deal with the bad names forever.

- Jonathan M Davis

On 2012-07-15 23:58, Walter Bright wrote:

> We did do a stable release, D1, and there were plenty of complaints that
> D1 did not get new features.

Yes because it was just an arbitrary release that was picked, with seemingly not much though behind.

> Also, all the released versions of D are available for download. There
> is no need to constantly download the latest if that disrupts your
> projects.

Then when you hit a bug and you ask the community they say that was fixed in the previous release, "you should always use the latest release".

-- 
/Jacob Carlborg

On Monday, July 16, 2012 09:25:54 Jacob Carlborg wrote:
> On 2012-07-16 02:20, Jonathan M Davis wrote:
> > If someone has a better proposal, they should make it (though probably in
> > a
> > separate thread - this one's long enough as it is). I think that the
> > basics of this proposal are good, and a lot of projects work that way. I
> > just think that D needs to be more stable before we worry about having
> > major and minor releases or stable and unstable branches.
> 
> Wasn't that what you just said two posts up? To have major and minor releases. Major containing new features and minor only bug fixes.

Isn't that essentially whan the OP's proposal was? We'd have 2.x.y where x is for major releases and y is for minor releases, with only bug fixes being permitted in minor releases. I don't think that I've proposed any other versioning schemes than what the OP was proposing. If I did, I misunderstood something.

- Jonathan M Davis

On 2012-07-16 03:11, Andrei Alexandrescu wrote:

> I wonder if it's possible that that person cherry-picks commits from
> HEAD into two separate branches: bugfixes and unstable. It should be
> easy to create installers etc. for those.

What would the difference between unstable and HEAD be?

-- 
/Jacob Carlborg

On 2012-07-16 03:11, Andrei Alexandrescu wrote:
> On 7/15/12 7:44 PM, Adam Wilson wrote:
>> I should note that we use this exact model for every project we have
>> where I work and that it is been highly successful at keeping those five
>> points of tension moderated. And our users can actually get work done
>> without waiting for weeks and months because thing X is just plain
>> broken, which in turn makes us look good. (Improving Loyalty)
>
> Allow me to propose something.
>
> Right now all dmd changes get merged in the head. Suppose we find a
> volunteer in the community who is:
>
> 1. Highly motivated
>
> 2. With a good understanding of D
>
> 3. Expert with git
>
> 4. Reliable
>
> I wonder if it's possible that that person cherry-picks commits from
> HEAD into two separate branches: bugfixes and unstable. It should be
> easy to create installers etc. for those.
>
> If we see this works well and gathers steady interest, we can improve it
> and make it the practice of the entire team.

Another idea to start with would be to create new temporary branches for bigger changes, i.e. COFF/Win64.

-- 
/Jacob Carlborg