"Walter Bright" <newshound@digitalmars.com> wrote in message news:e8n9mi$2flp$1@digitaldaemon.com...
> Kyle Furlong wrote:
>> *Standing Ovation*
>
> Yeah, that's concerned me as well. But it isn't just me trying to make it perfect, everyone's got their favorite bug/feature that must get in before 1.0.
>
> So what do you say we just call D right now *1.0* and move on? It's not like D will stop undergoing improvements.

I've taken the liberty of making this a new thread as the old one was getting a little long.

Walters post raises the issue of exactly what criteria should be used to determine when D reaches a state suitable for a 1.0 release.

My personal take is that it should be a 1.0 release when Walter believes that all of the language changes which are expected to break existing code have been made.  For example, if he expects to add any further reserved words, reserve them (even if not presently implemented) prior to the 1.0 release.  Also, any change which alters the semantics of an existing feature and thus breaks existing code should be made prior to 1.0.

This still leaves bug fixing and additional language features which don't break existing code for post-1.0 releases.

Tony
Melbourne, Australia

Tony wrote:
> "Walter Bright"  wrote 
>>So what do you say we just call D right now *1.0* and move on? It's not
>>like D will stop undergoing improvements.
> 
> 
> I've taken the liberty of making this a new thread as the old one was getting a little long.
> 
> Walters post raises the issue of exactly what criteria should be used to determine when D reaches a state suitable for a 1.0 release.
> 
> My personal take is that it should be a 1.0 release when Walter believes that all of the language changes which are expected to break existing code have been made.  For example, if he expects to add any further reserved words, reserve them (even if not presently implemented) prior to the 1.0 release.  Also, any change which alters the semantics of an existing feature and thus breaks existing code should be made prior to 1.0.
> 
> This still leaves bug fixing and additional language features which don't break existing code for post-1.0 releases.



Hear Hear!

One thing to add, though, is a certain /level of expectation/ should be accomodated without significant issue. We don't want to announce a grand opening, so to speak, and have loads of new folks rush through the doors and simply fall through holes in the floor. Would be a public-relations disaster.

Given that aspect, I suspect there's still certain outstanding "major issues" that really ought to be addressed first? There's no point in jumping the gun if you're going to take a dive at the first hurdle.

Would there a problem with setting a schedule for release, rather than just being a tad reactive? I mean, what's another month or two to those who really want the language to succeed?

kris wrote:
> Tony wrote:
>> "Walter Bright"  wrote
>>> So what do you say we just call D right now *1.0* and move on? It's not
>>> like D will stop undergoing improvements.
>>

My vote too, but in line with what Kris mentions below I think it's important to see the following addressed either through better docs. or (if it is a bug) a fix for v1.0:

http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/7649

- Dave

>>
>> I've taken the liberty of making this a new thread as the old one was getting a little long.
>>
>> Walters post raises the issue of exactly what criteria should be used to determine when D reaches a state suitable for a 1.0 release.
>>
>> My personal take is that it should be a 1.0 release when Walter believes that all of the language changes which are expected to break existing code have been made.  For example, if he expects to add any further reserved words, reserve them (even if not presently implemented) prior to the 1.0 release.  Also, any change which alters the semantics of an existing feature and thus breaks existing code should be made prior to 1.0.
>>
>> This still leaves bug fixing and additional language features which don't break existing code for post-1.0 releases.
> 
> Hear Hear!
> 
> One thing to add, though, is a certain /level of expectation/ should be accomodated without significant issue. We don't want to announce a grand opening, so to speak, and have loads of new folks rush through the doors and simply fall through holes in the floor. Would be a public-relations disaster.
> 
> Given that aspect, I suspect there's still certain outstanding "major issues" that really ought to be addressed first? There's no point in jumping the gun if you're going to take a dive at the first hurdle.
> 
> Would there a problem with setting a schedule for release, rather than just being a tad reactive? I mean, what's another month or two to those who really want the language to succeed?

Tony wrote:

> "Walter Bright" <newshound@digitalmars.com> wrote in message news:e8n9mi$2flp$1@digitaldaemon.com...
>> Kyle Furlong wrote:
>>> *Standing Ovation*
>>
>> Yeah, that's concerned me as well. But it isn't just me trying to make it perfect, everyone's got their favorite bug/feature that must get in before 1.0.
>>
>> So what do you say we just call D right now *1.0* and move on? It's not like D will stop undergoing improvements.
> 
> I've taken the liberty of making this a new thread as the old one was getting a little long.
> 
> Walters post raises the issue of exactly what criteria should be used to determine when D reaches a state suitable for a 1.0 release.
> 
> My personal take is that it should be a 1.0 release when Walter believes that all of the language changes which are expected to break existing code have been made.  For example, if he expects to add any further reserved words, reserve them (even if not presently implemented) prior to the 1.0 release.  Also, any change which alters the semantics of an existing feature and thus breaks existing code should be made prior to 1.0.
> 
> This still leaves bug fixing and additional language features which don't break existing code for post-1.0 releases.
> 
> Tony
> Melbourne, Australia

With the latest posts on template issues (some are labeled bugs, some are labeled 2.0), I believe there are two major problems with the current implementation and/or specification (and a whole bunch of niggles, but those might just qualify as bugs):

 - The const issue
 - Visibility and accessibility rules

I think both are far from being able to be labeled as "just bugs", and if any of them are fixed with steel wire and strong tape, then they will be revisited with double strength post 1.0 release.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource & #D: larsivi

Tony wrote:
<snip>
> Walters post raises the issue of exactly what criteria should be used to determine when D reaches a state suitable for a 1.0 release.
> 
> My personal take is that it should be a 1.0 release when Walter believes that all of the language changes which are expected to break existing code have been made.  For example, if he expects to add any further reserved words, reserve them (even if not presently implemented) prior to the 1.0 release.  Also, any change which alters the semantics of an existing feature and thus breaks existing code should be made prior to 1.0.
<snip>

Yes, that's part of it.  AISI the prerequisites for 1.0 readiness are:
(a) a clear, complete and consistent spec
(b) a fully documented and reasonably clean standard library
(c) all known serious compiler bugs and most not-so-serious compiler bugs fixed
(d) as you say, sufficient stability that any language or standard library changes are unlikely to break existing code
(e) agreement among all of us that the above have been achieved

Stewart.

Stewart Gordon wrote:
> Tony wrote:
> <snip>
>> Walters post raises the issue of exactly what criteria should be used to determine when D reaches a state suitable for a 1.0 release.
>>
>> My personal take is that it should be a 1.0 release when Walter believes that all of the language changes which are expected to break existing code have been made.  For example, if he expects to add any further reserved words, reserve them (even if not presently implemented) prior to the 1.0 release.  Also, any change which alters the semantics of an existing feature and thus breaks existing code should be made prior to 1.0.
> <snip>
> 
> Yes, that's part of it.  AISI the prerequisites for 1.0 readiness are:
> (a) a clear, complete and consistent spec
> (b) a fully documented and reasonably clean standard library
> (c) all known serious compiler bugs and most not-so-serious compiler bugs fixed
> (d) as you say, sufficient stability that any language or standard library changes are unlikely to break existing code
> (e) agreement among all of us that the above have been achieved

I don't think that any of those are achievable until a 1.0 language feature freeze happens. The language needs to be stable for months before there's any chance of a 1.0 library such as you describe.

And I think that (e) is impossible.

In article <e90ai8$26ve$1@digitaldaemon.com>, Stewart Gordon says...
>
>Tony wrote:
><snip>
>> Walters post raises the issue of exactly what criteria should be used to determine when D reaches a state suitable for a 1.0 release.
>> 
>> My personal take is that it should be a 1.0 release when Walter believes that all of the language changes which are expected to break existing code have been made.  For example, if he expects to add any further reserved words, reserve them (even if not presently implemented) prior to the 1.0 release.  Also, any change which alters the semantics of an existing feature and thus breaks existing code should be made prior to 1.0.
><snip>
>
>Yes, that's part of it.  AISI the prerequisites for 1.0 readiness are: (a) a clear, complete and consistent spec

That'd be nice. I don't know if the current gaps in the spec are big enough to prevent D 1.0 though.


>(b) a fully documented and reasonably clean standard library

I don't think we should wait that long. Phobos isn't perfect, but I think it's good enough for D 1.0.


>(c) all known serious compiler bugs and most not-so-serious compiler bugs fixed

I think there could be quite a few not-so-serious compiler bugs in D 1.0 release. But they have to be hard to find for D newcomers.


>(d) as you say, sufficient stability that any language or standard library changes are unlikely to break existing code

Or at least, the code wouldn't break until around D 2.0.


>(e) agreement among all of us that the above have been achieved

I hope by "all of us" you mean "most of us" or "many of us" because "all of us" won't ever happen.

jcc7

jcc7 wrote:
>> Tony wrote:
>> (b) a fully documented and reasonably clean standard library
> 
> I don't think we should wait that long. Phobos isn't perfect, but I think it's
> good enough for D 1.0.
> 

I agree on that. As I see it phobos is a library using a very productive style, through sometimes their is parts missing. A good standard library dont have to bee bloated or monolithic. However I think their is a few issues in phobos that need to be fixed before 1.0, most notably string functions for wchar[] and dchar[] and standard containers (others can certainly think of other things). But I think that thees shortcomings can bee quickly solved (a few months maybe 1 or 2) once we get a feature freeze of the specification.

In article <e90gih$2f7i$1@digitaldaemon.com>, Johan Granberg says...
>
>jcc7 wrote:
>>> Tony wrote:
>>> (b) a fully documented and reasonably clean standard library
>> 
>> I don't think we should wait that long. Phobos isn't perfect, but I think it's good enough for D 1.0.
>> 
>
>I agree on that. As I see it phobos is a library using a very productive style, through sometimes their is parts missing. A good standard library dont have to bee bloated or monolithic. However I think their is a few issues in phobos that need to be fixed before 1.0, most notably string functions for wchar[] and dchar[] and standard containers (others can certainly think of other things). But I think that thees shortcomings can bee quickly solved (a few months maybe 1 or 2) once we get a feature freeze of the specification.

I just think calling it "D 1.0" is about the language specification being frozen (which could happen soon), and the standard library doesn't need to be fully fleshed out for D 1.0. It'd be nice if it were (I'm not trying discourage people from pointing out the problems in Phobos or offering fixes), but I think D 1.0 needs to arrive sooner rather than later to help with D's public image.

D has been in development for many years, and eventually people just shrug and say, "Yeah, D might be nice, but it's just an experiment with no major releases in sight".

jcc7

jcc7 wrote:
> I just think calling it "D 1.0" is about the language specification being frozen
> (which could happen soon), and the standard library doesn't need to be fully
> fleshed out for D 1.0. It'd be nice if it were (I'm not trying discourage people
> from pointing out the problems in Phobos or offering fixes), but I think D 1.0
> needs to arrive sooner rather than later to help with D's public image. 
> 
> D has been in development for many years, and eventually people just shrug and
> say, "Yeah, D might be nice, but it's just an experiment with no major releases
> in sight".
> 
> jcc7
I'm not speaking of a fully fleshed out phobos I just noted a few issues that I think should bee fixed before 1.0. I agree that a 1.0 should bee released soon, a good target release date would bee in october, september. that way we could have a feature freeze in the language in august and make some cleanup (bugs and phobos) before 1.0.