On Thu, Mar 26, 2009 at 6:07 PM, Walter Bright <newshound1@digitalmars.com> wrote:
>
> But that's why the download page divides the downloads into "latest" and "stable." If you want "stable", why download "latest"?

Stable doesn't just mean "not changing."  It also means "providing a strong foundation upon which something can be built."  The older compilers are usually anything but that, as the newer ones usually fix more things than what they break.  The library developers are forced to use newer compilers because there are showstopping bugs in the older ones, and the library users are then forced to use newer compilers as a result.  At least, that's what I've experienced.

> Furthermore, before release, it is made available to the DWT and Tango teams to see if it breaks them. If I made it generally available, how is that different from the "latest" on the download page? There's even a "bundle" version that comes with various libraries tested and verified with it.

Well usually problems only arise when things change - directory structure, new features, language spec changes (.init).  Bugfixes rarely create problems.  For example I'd welcome fixes to things like bugs 313 and 314 (which are ancient, by the way) even if it means I have to change my code, because I know that my code is more correct as a result.  I feel like the idea behind the nightly releases is so that when _changes_ occur, or when regressions are introduced, they can be stamped out before a major release.  DWT and Tango are major projects but are by no means an exhaustive testbed.

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.

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.

Walter Bright schrieb:
> As for the does one develop stable code targeting D1 and D2, I would suggest targeting D1 but be careful to use the string alias for all the char[]'s, and treat strings as if they were immutable. This will cover 90% of any source code changes between D1 and D2, perhaps even more than 90%. It's also very possible to write D1 code using the immutability style, in fact, I advocated it long before D2 (see all the old threads discussing Copy On Write).

Well, using the string alias leads to problems, esp. when used as a function parameter:
int func(string str)

This makes it impossible to pass a mutable string to the function in D2.

I personally use an  alias const(char)[] cstring;  for most of my parameters and  alias invariant(char)[] istring;  for normal immutable strings.

On Thu, Mar 26, 2009 at 7:01 PM, 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.

It's not the bugs that you know about that cause problems for other people!

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.

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).

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
Algún día los libros desterrarán a la radio y el hombre descubrirá el
oculto poder del Amargo Serrano.
	-- Ricardo Vaporeso. El Bolsón, 1909.

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.

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
 ease, eating well (no more microwave dinners and saturated fats),
a patient better driver, a safer car (baby smiling in back seat),
sleeping well (no bad dreams), no paranoia,

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).

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

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