D versionning

Adam Wilson flyboynw at gmail.com
Sun Jul 15 16:44:45 PDT 2012


On Sun, 15 Jul 2012 16:06:58 -0700, Walter Bright  
<newshound2 at digitalmars.com> wrote:

> On 7/15/2012 3:52 PM, Adam Wilson wrote:
>> So the problem is semantics then? Because I dredge up another word to  
>> describe
>> what we are asking for if that's all it takes. But I don't think that  
>> anyone
>> else is going to read "stable" as "unchanging". Software is by  
>> definition
>> changing, or it's dead. It appears to my parsing of your sentence that  
>> you are
>> asserting that stable == static. By that definition of stable, Windows  
>> ME is
>> "stable" and ... ehrm, not a soul in the tech world would agree with  
>> that
>> summation of WinME.
>>
>> As I said earlier, no one else in FOSS or Commercial equates stable  
>> with "has no
>> bugs", it means no new features and no regressions. Not a single  
>> solitary person
>> I've talked too expects their software to be bug free.
>>
>> THIS is what we mean when we say "stable":
>> http://www.modernperlbooks.com/mt/2009/06/what-does-stable-mean.html
>> It's also how pretty much everyone else will read "stable".
>
> D does have a test suite, and it is a (almost always achieved) goal to  
> keep it always passing, even on the dev branch. In fact, most of my work  
> is running the test suite and making sure each change doesn't regress.  
> (Regressions that do slip through were not in the test suite.)
>
> Frankly, I don't know how to do what you're asking for. D users, every  
> single day, clamor for:
>
> 1. more bug fixes

Branch A. Rebase into Branch B as needed.

> 2. more new features

Branch B.

> 3. why aren't deprecated features removed more quickly?

Branch A, marked for deprecation.
Branch B, actually removed. Becomes active when merged into Branch A.
(Assuming Branch B is merged roughly every other month as per current  
processes.)

> 4. why don't we add this breaking feature?

Add it. Branch B.

> 5. why did you add that breaking feature which broke my code?

Why are you using Branch B you knucklehead?

> Often, these are the same people! Sometimes, even in the same post!

This concept is precisely designed to significantly mitigate all five  
problems.

Not everyone will test against Repo B, but this allows you to put the  
responsibility for not testing against it on them. They know how it works  
here, it's not your problem if you broke something that they had the  
chance to test for but didn't.

> 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 do apologize for that. It is not my intention to cause undue stress. I  
am pushing the for the change because I think it will mitigate much of  
your current stress in dealing with us. And I do recognize that we users  
can be pretty demanding as I sit on the other side of this equation at  
work. But because I sit on the other side, I get frustrated when I see  
developers actively resisting the proven concepts that will drastically  
reduce the very problem they are complaining about.

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)

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


More information about the Digitalmars-d mailing list