View mode: basic / threaded / horizontal-split · Log in · Help
July 16, 2012
Re: D versionning
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 ?
July 16, 2012
Re: D versionning
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
July 16, 2012
Re: D versionning
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/
July 16, 2012
Re: D versionning
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
July 16, 2012
Re: D versionning
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
July 16, 2012
Re: D versionning
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/
July 16, 2012
Re: D versionning
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
July 16, 2012
Re: D versionning
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
July 16, 2012
Re: D versionning
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/
July 16, 2012
Re: D versionning
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
4 5 6 7 8 9 10 11 12
Top | Discussion index | About this forum | D home