On Fri, Mar 27, 2009 at 12:29 AM, Walter Bright <newshound1@digitalmars.com> wrote:
> Leandro Lucarella wrote:
>>
>> Walter Bright, el 26 de marzo a las 16:58 me escribiste:
>>>
>>> Jarrett Billingsley wrote:
>>>>
>>>> It's not the bugs that you know about that cause problems for other people!
>>>
>>> Half-baked implementations won't help them, either. I just don't think the answer is, what is in essence, a lot more releases.
>>
>> Millions of open source projects that work that way can prove you wrong.
>
> Phobos works that way, and intermediate "releases" are pretty much ignored (as I think they should be).
>

Maybe it's because no one uses it.

I mean, I'm just saying.

On Fri, Mar 27, 2009 at 1:19 AM, Jarrett Billingsley <jarrett.billingsley@gmail.com> wrote:
> On Fri, Mar 27, 2009 at 12:29 AM, Walter Bright <newshound1@digitalmars.com> wrote:
>> Leandro Lucarella wrote:
>>>
>>> Walter Bright, el 26 de marzo a las 16:58 me escribiste:
>>>>
>>>> Jarrett Billingsley wrote:
>>>>>
>>>>> It's not the bugs that you know about that cause problems for other people!
>>>>
>>>> Half-baked implementations won't help them, either. I just don't think the answer is, what is in essence, a lot more releases.
>>>
>>> Millions of open source projects that work that way can prove you wrong.
>>
>> Phobos works that way, and intermediate "releases" are pretty much ignored (as I think they should be).
>>
>
> Maybe it's because no one uses it.
>
> I mean, I'm just saying.
>

This is also partly the beer talking.

Bill Baxter wrote:
> It seems to me the only people who would know which compilers deserve
> the "stable" label are the folks using dmd on a daily basis to build
> their software.  Yet I've never seen the question come up here or
> anywhere else of what version of D the users find to be the most
> stable.   My impression is frankly that Walter just arbitrarily slaps
> the label on a rev that's about 10 steps back from current.  Probably
> there's more to it than that, but that's what it seems like.

The current "stable" D1 is that way because it's the one that people supplied me with a bundled version that has the major libraries specifically tested and working with it.

I think that is a fairly reasonable definition of it.

Leandro Lucarella wrote:
> Sean Kelly, el 26 de marzo a las 22:08 me escribiste:
>> == Quote from Leandro Lucarella (llucax@gmail.com)'s article
>>> D situation is a little different because D2 is already here, and it's too
>>> much ahead of D1. So a plan to backport features from D2 to D1
>>> progressively should be done.
>> Who is going to do these backports?
> 
> That's a fair question without an answer =)
> (I wish I had the time to do it. If I had the time I probably first do it
> and then propose it)
> 
>> Personally, I'd rather think about moving my code to D2 in one jump than
>> in a bunch of incremental steps, each requiring a custom compiler.
> 
> Are you? If not, why? I think D2 being a moving target make people don't
> want to port code because it would be too hard to maintain. They idea
> behind 1.x series is that each minor version is *stable*. Code you port
> to, let's say, 1.1.000, will work with 1.1.100. No new predefined
> versions, no new nothing. You get a really stable language and one that
> evolves fast. You just have to do some minor porting about once a year,
> when a new minor version is release, and that porting should be trivial.
> Porting code to D2 now is a complicated excercise, at least to do it right
> (using constness features).
> 

You'd get the same effect if we had a stable D2. Which we don't yet have, but it feels to me that it's converging.

Brad Roberts wrote:
> Bill Baxter wrote:
>> On Fri, Mar 27, 2009 at 1:03 PM, Leandro Lucarella <llucax@gmail.com> wrote:
>>> Walter Bright, el 26 de marzo a las 16:58 me escribiste:
>>>> Jarrett Billingsley wrote:
>>>>> It's not the bugs that you know about that cause problems for other people!
>>>> Half-baked implementations won't help them, either. I just don't think
>>>> the answer is, what is in essence, a lot more releases.
>>> Millions of open source projects that work that way can prove you wrong.
>>
>> I think part of the problem with the current approach is that the
>> "stable" D releases seem to have no connection with reality.  It's
>> always been way older than it should be every time I've looked.  I
>> wouldn't recommend that anyone use 1.030 right now.  I'd say 1.037
>> should be the most recent "stable" version at the moment.   It seems
>> there isn't a good process in place for figuring out what's stable and
>> what's not.
>>
>> It seems to me the only people who would know which compilers deserve
>> the "stable" label are the folks using dmd on a daily basis to build
>> their software.  Yet I've never seen the question come up here or
>> anywhere else of what version of D the users find to be the most
>> stable.   My impression is frankly that Walter just arbitrarily slaps
>> the label on a rev that's about 10 steps back from current.  Probably
>> there's more to it than that, but that's what it seems like.
>>
>> --bb
> 
> Actually it's more like he moves it forward when conversations like this
> come up and point out how far behind it is.  I'm not sure I've seen it
> ever pro-actively moved forward, only re-actively. :)
> 
> Later,
> Brad

Yes. I think I was responsible for the provoking two of the three changes that have occured. I don't like that at all. I think what's really lacking is a process for declaring a revision as stable. Then, library developers would need to agree to make sure to verify that everything works with the last version which is declared as stable.

It'd also be nice to mark in the changelog as soon as a version is known to be broken, so that more people don't download it.

Leandro Lucarella Wrote:

> Sean Kelly, el 26 de marzo a las 22:08 me escribiste:
> > == Quote from Leandro Lucarella (llucax@gmail.com)'s article
> > >
> > > D situation is a little different because D2 is already here, and it's too much ahead of D1. So a plan to backport features from D2 to D1 progressively should be done.
> > 
> > Who is going to do these backports?
> 
> That's a fair question without an answer =)
> (I wish I had the time to do it. If I had the time I probably first do it
> and then propose it)
> 
> > Personally, I'd rather think about moving my code to D2 in one jump than in a bunch of incremental steps, each requiring a custom compiler.
> 
> Are you? If not, why? I think D2 being a moving target make people don't want to port code because it would be too hard to maintain. They idea behind 1.x series is that each minor version is *stable*. Code you port to, let's say, 1.1.000, will work with 1.1.100. No new predefined versions, no new nothing. You get a really stable language and one that evolves fast. You just have to do some minor porting about once a year, when a new minor version is release, and that porting should be trivial. Porting code to D2 now is a complicated excercise, at least to do it right (using constness features).

I think many people avoid D2 because it has const and that const is too much work for too little gain. Many seem to want all features of D2 without the const. I don't really get any of the anti D2 arguments except that D2 lacks Tango. I pushed hard trying to see something official in that area, including offering my time totest/fix Tango after breaking D2 changes. I've given up on the whole mess.

Walter Bright, el 26 de marzo a las 21:29 me escribiste:
> Leandro Lucarella wrote:
> >Walter Bright, el 26 de marzo a las 16:58 me escribiste:
> >>Jarrett Billingsley wrote:
> >>>It's not the bugs that you know about that cause problems for other people!
> >>Half-baked implementations won't help them, either. I just don't think the answer is, what is in essence, a lot more releases.
> >Millions of open source projects that work that way can prove you wrong.
> 
> Phobos works that way, and intermediate "releases" are pretty much ignored (as I think they should be).

I do follow the development of phobos (and reported some minor issues when
I saw them).

And making beta or at least rc releases would help a lot too, because
a lot of people will be willing to download the rc and test it with its
software to see if all works good and report problems so they are fixed in
the release.

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
heart that's full up like a landfill,
a job that slowly kills you,
bruises that won't heal.

Don, el 27 de marzo a las 10:58 me escribiste:
> Brad Roberts wrote:
> >Bill Baxter wrote:
> >>On Fri, Mar 27, 2009 at 1:03 PM, Leandro Lucarella <llucax@gmail.com> wrote:
> >>>Walter Bright, el 26 de marzo a las 16:58 me escribiste:
> >>>>Jarrett Billingsley wrote:
> >>>>>It's not the bugs that you know about that cause problems for other people!
> >>>>Half-baked implementations won't help them, either. I just don't think the answer is, what is in essence, a lot more releases.
> >>>Millions of open source projects that work that way can prove you wrong.
> >>
> >>I think part of the problem with the current approach is that the "stable" D releases seem to have no connection with reality.  It's always been way older than it should be every time I've looked.  I wouldn't recommend that anyone use 1.030 right now.  I'd say 1.037 should be the most recent "stable" version at the moment.   It seems there isn't a good process in place for figuring out what's stable and what's not.
> >>
> >>It seems to me the only people who would know which compilers deserve the "stable" label are the folks using dmd on a daily basis to build their software.  Yet I've never seen the question come up here or anywhere else of what version of D the users find to be the most stable.   My impression is frankly that Walter just arbitrarily slaps the label on a rev that's about 10 steps back from current.  Probably there's more to it than that, but that's what it seems like.
> >>
> >>--bb
> >Actually it's more like he moves it forward when conversations like this
> >come up and point out how far behind it is.  I'm not sure I've seen it
> >ever pro-actively moved forward, only re-actively. :)
> >Later,
> >Brad
> 
> Yes. I think I was responsible for the provoking two of the three changes that have occured. I don't like that at all. I think what's really lacking is a process for declaring a revision as stable. Then, library developers would need to agree to make sure to verify that everything works with the last version which is declared as stable.
> 
> It'd also be nice to mark in the changelog as soon as a version is known to be broken, so that more people don't download it.

Make beta/release candidate release!

If code is in a SCM is much more simpler, you can simply say: "hey,
people, a new release is comming next week, can you download current <SCM>
version and see if all works good?". You don't even have to go throgh
a complete release process.

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
ASALTAN, GOLPEAN SALVAJEMENTE A ANCIANA Y LE COMEN LA PASTAFROLA.
	-- Crónica TV

Thu, 26 Mar 2009 22:30:50 -0700, Walter Bright wrote:

> Bill Baxter wrote:
>> It seems to me the only people who would know which compilers deserve the "stable" label are the folks using dmd on a daily basis to build their software.  Yet I've never seen the question come up here or anywhere else of what version of D the users find to be the most stable.   My impression is frankly that Walter just arbitrarily slaps the label on a rev that's about 10 steps back from current.  Probably there's more to it than that, but that's what it seems like.
> 
> The current "stable" D1 is that way because it's the one that people supplied me with a bundled version that has the major libraries specifically tested and working with it.
> 
> I think that is a fairly reasonable definition of it.

Official stable Tango is bundled with 1.033 for a very long time already.

On Fri, Mar 27, 2009 at 12:01 AM, Walter Bright <newshound1@digitalmars.com> wrote:
> Jarrett Billingsley wrote:
>>
>> So what about the following counterargument: "even if nightly builds were made available, how can we be sure that enough people are using them to sufficiently test them?"  OK, sure, if not many people are using the nightly builds, then there wouldn't be much benefit.  But it does seem to work out fine for a lot of projects.  And with a proper SCM set up which you commit to daily, there's virtually no work on your part.  You just commit, and everyone else can download and compile.
>
> I believe that people downloading half-baked works in progress and then finding problems I already know about and am fixing is probably not more productive.
>

Some of us might actually look at your changes.

1) We get a forewarning for changes that might affect LDC/GDC/D.NET etc.

2) We can comment on changes. Ideally there would be a mailing list with each commit. This makes discussion of specific changes much easier.

3) You get feedback on the code.

I'm not sure how many people have access to your code, or if you even use a SCM repository locally.

As an extra bonus you could release your internal test suite as well. This would be useful for projects like LDC, as a compliment to DStress. Do you use Dstress?

The testing process of DMD could be much less opaque in general.

-Tomas