On 16/07/2012 01:42, Jonathan M Davis wrote:
> On Sunday, July 15, 2012 16:26:50 Walter Bright wrote:
>> Sigh. Half say we release too often, the other half not often enough.
>
> Which is actually one argument for going to a model where you have frequent
> minor releases which only contain bug fixes and less frequent major releases
> with the larger changes. You can never make everyone happy, but by doing so,
> you get the bug fixes faster for the folks complaining about the lack of
> frequent releases, and you get increased stability as far as the new stuff
> goes, because it doesn't come with every release.
>
> I'm only against the proposed versioning scheme because I think that we need
> to stabilize things better (e.g. actually have all of the features that TDPL
> lists fully implemented) before we move to it. But I fully support moving to
> this sort of scheme in the long run. It manages change much better, and I
> think that many, many existing projects have shown that it promotes stable
> code bases while still allowing for them to evolve as necessary.
>
> - Jonathan M Davis

The proposed scheme is only a proposed scheme. Other solutions exist that solve the problem, and if they better fit, why not ?

On Monday, July 16, 2012 02:07:13 deadalnix wrote:
> On 16/07/2012 01:42, Jonathan M Davis wrote:
> > On Sunday, July 15, 2012 16:26:50 Walter Bright wrote:
> >> Sigh. Half say we release too often, the other half not often enough.
> > 
> > Which is actually one argument for going to a model where you have
> > frequent
> > minor releases which only contain bug fixes and less frequent major
> > releases with the larger changes. You can never make everyone happy, but
> > by doing so, you get the bug fixes faster for the folks complaining about
> > the lack of frequent releases, and you get increased stability as far as
> > the new stuff goes, because it doesn't come with every release.
> > 
> > I'm only against the proposed versioning scheme because I think that we need to stabilize things better (e.g. actually have all of the features that TDPL lists fully implemented) before we move to it. But I fully support moving to this sort of scheme in the long run. It manages change much better, and I think that many, many existing projects have shown that it promotes stable code bases while still allowing for them to evolve as necessary.
> > 
> > - Jonathan M Davis
> 
> The proposed scheme is only a proposed scheme. Other solutions exist that solve the problem, and if they better fit, why not ?

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.

- Jonathan M Davis

On Sun, 15 Jul 2012 17:20:33 -0700, Jonathan M Davis <jmdavisProg@gmx.com> wrote:

> On Monday, July 16, 2012 02:07:13 deadalnix wrote:
>> On 16/07/2012 01:42, Jonathan M Davis wrote:
>> > On Sunday, July 15, 2012 16:26:50 Walter Bright wrote:
>> >> Sigh. Half say we release too often, the other half not often enough.
>> >
>> > Which is actually one argument for going to a model where you have
>> > frequent
>> > minor releases which only contain bug fixes and less frequent major
>> > releases with the larger changes. You can never make everyone happy,  
>> but
>> > by doing so, you get the bug fixes faster for the folks complaining  
>> about
>> > the lack of frequent releases, and you get increased stability as far  
>> as
>> > the new stuff goes, because it doesn't come with every release.
>> >
>> > I'm only against the proposed versioning scheme because I think that  
>> we
>> > need to stabilize things better (e.g. actually have all of the  
>> features
>> > that TDPL lists fully implemented) before we move to it. But I fully
>> > support moving to this sort of scheme in the long run. It manages  
>> change
>> > much better, and I think that many, many existing projects have shown
>> > that it promotes stable code bases while still allowing for them to
>> > evolve as necessary.
>> >
>> > - Jonathan M Davis
>>
>> The proposed scheme is only a proposed scheme. Other solutions exist
>> that solve the problem, and if they better fit, why not ?
>
> 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.
>
> - Jonathan M Davis

I guess I just see it as differing definitions of "stable". For example, dsimcha was here not twenty hours ago praising D for how stable it's become.

I think this is a pretty good summation of stable in the community project context:
http://www.modernperlbooks.com/mt/2009/06/what-does-stable-mean.html

Note: We meet all criteria for stable.

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/

On Sunday, July 15, 2012 17:23:44 Adam Wilson wrote:
> I guess I just see it as differing definitions of "stable". For example, dsimcha was here not twenty hours ago praising D for how stable it's become.
> 
> I think this is a pretty good summation of stable in the community project context: http://www.modernperlbooks.com/mt/2009/06/what-does-stable-mean.html
> 
> Note: We meet all criteria for stable.

What I want to see is dmd having fully implemented all of the features in TDPL (e.g. multiple alias thises) and sorted out all of the major design or implementation issues (e.g. the issues with const and Object). After that, D2 has been fully implemented, and we can look at adding new features if we want to and restricting those as well as any breaking changes that we need to make to a different branch which only gets merged into the main branch in certain releases.

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.

- Jonathan M Davis

On 7/15/12 7:06 PM, Walter Bright wrote:
> Frankly, I don't know how to do what you're asking for. D users, every
> single day, clamor for:
>
> 1. more bug fixes
> 2. more new features
> 3. why aren't deprecated features removed more quickly?
> 4. why don't we add this breaking feature?
> 5. why did you add that breaking feature which broke my code?
>
> Often, these are the same people! Sometimes, even in the same post!
>
> And, to reiterate, we did release D1. Since its release, it has only
> received bug fixes. No breaking changes, no regressions. This,
> inevitably, has made many D1 users unhappy - they wanted new features
> folded in.
>
> So that was not satisfactory, either.
>
> Yes, I do feel a bit put upon by this, as I see no way to satisfy all
> these mutually contradictory requests.

I think you're conflating two different trends. One is the annoying one you mentioned, and the other is a very reasonable request - that D has one branch containing only bug fixes, and another branch with new features and other potentially disruptive things.

The key is that the branches are merged once a more risky branch is stable enough, and the essential ingredient is that git makes branch merging easy.

This is not something you could have done essentially at any pre-github time in D's history, and is not to be confused with D1 vs D2 or with the known contradictory requests.


Andrei

On Sun, 15 Jul 2012 17:36:28 -0700, Jonathan M Davis <jmdavisProg@gmx.com> wrote:

> On Sunday, July 15, 2012 17:23:44 Adam Wilson wrote:
>> I guess I just see it as differing definitions of "stable". For example,
>> dsimcha was here not twenty hours ago praising D for how stable it's
>> become.
>>
>> I think this is a pretty good summation of stable in the community project
>> context:
>> http://www.modernperlbooks.com/mt/2009/06/what-does-stable-mean.html
>>
>> Note: We meet all criteria for stable.
>
> What I want to see is dmd having fully implemented all of the features in TDPL
> (e.g. multiple alias thises) and sorted out all of the major design or
> implementation issues (e.g. the issues with const and Object). After that, D2
> has been fully implemented, and we can look at adding new features if we want
> to and restricting those as well as any breaking changes that we need to make
> to a different branch which only gets merged into the main branch in certain
> releases.
>
> 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.
>
> - Jonathan M Davis

I think the problem is that in the real world, that state is somewhat unlikely. For example, Walter is currently working on COFF support, this is arguably a new feature (we already can make programs work on Windows). Programmers aren't machines and fixing bugs all day is boring, we want to do the fun stuff, in this case, new features. It just so happens that it's the fun stuff that makes fixing bugs bearable. I don't think it's fair of us to demand that Walter only fix bugs, besides, COFF support is a HIGHLY requested new feature, he is just supposed to ignore them?

It is never easy deciding which new features to add versus which bugs to fix, but that's the beauty of this model, you don't have to. You just do both.

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/

On Sunday, July 15, 2012 20:43:52 Andrei Alexandrescu wrote:
> The key is that the branches are merged once a more risky branch is stable enough, and the essential ingredient is that git makes branch merging easy.

Yes. This is a huge advantage to using git. It's actually reasonably sane to maintain multiple branches.

- Jonathan M Davis

On 7/15/12 7:15 PM, Patrick Stewart wrote:
> We are coming back to dsource&  Tango graveyard story. D had equally
> capable and large community to. Its resources got wasted. People
> left. Huge amount of work just wasted for nothing.

Actually a couple of weeks ago I was curious and collected a few statistics about the frequency of posts, number of posters, and such. The numbers are not yet in shape to be published, but from what I gathered so far there was no visible glitch around the D1/D2 divergence. There's a strong increase since 2011, but I couldn't yet gather an exponential trend.

> On the other hand,
> Python has one of the largest *operational* standard library and tons
> of 3rd party ones. Why? Because with stable language, all those
> libraries stayed in the game.

Agreed, we have much to learn from Python and other successful languages.

I assume those procedures and protocols materialized together with strong growth of the community, and may be difficult to transplant to our team. Right now my main focus as an organizer is to make sure people's cycles are spent on productive, high-impact work. Right now Walter is working on Win64, which is of very high impact. A change of procedure right now would simply mean time taken away from that task.

Finally, since you are interested in effecting durable positive change in D's development, I'll venture that perhaps you're not going the best way about it. Your posts attempt almost with no exception to inflame, and there's no contribution I know of in your name. That all reduces the credibility of your points, however merit there may be in them.


Thanks,

Andrei

On Sun, 15 Jul 2012 18:01:41 -0700, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> On 7/15/12 7:15 PM, Patrick Stewart wrote:
>> We are coming back to dsource&  Tango graveyard story. D had equally
>> capable and large community to. Its resources got wasted. People
>> left. Huge amount of work just wasted for nothing.
>
> Actually a couple of weeks ago I was curious and collected a few statistics about the frequency of posts, number of posters, and such. The numbers are not yet in shape to be published, but from what I gathered so far there was no visible glitch around the D1/D2 divergence. There's a strong increase since 2011, but I couldn't yet gather an exponential trend.
>
>> On the other hand,
>> Python has one of the largest *operational* standard library and tons
>> of 3rd party ones. Why? Because with stable language, all those
>> libraries stayed in the game.
>
> Agreed, we have much to learn from Python and other successful languages.
>
> I assume those procedures and protocols materialized together with strong growth of the community, and may be difficult to transplant to our team. Right now my main focus as an organizer is to make sure people's cycles are spent on productive, high-impact work. Right now Walter is working on Win64, which is of very high impact. A change of procedure right now would simply mean time taken away from that task.
>
> Finally, since you are interested in effecting durable positive change in D's development, I'll venture that perhaps you're not going the best way about it. Your posts attempt almost with no exception to inflame, and there's no contribution I know of in your name. That all reduces the credibility of your points, however merit there may be in them.
>
>
> Thanks,
>
> Andrei

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.

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/

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.

Would this be possible?


Andrei