Time is running out.  Or rather, version numbers are running out.  (That is, unless my suggestion of 0.01 increments from now on is implemented.)

So, it's time to look at what's left before we can sensibly finally cross over the bridge to 1.0.

http://www.wikiservice.at/wiki4d/wiki.cgi?PendingPeeves

Since I started it, it has grown a bit, but has shrunk only in one or two little bits.  OK, so AssertError has finally been fixed, and with now works on structs.  As for context-free grammar, C-style casts have been deprecated, and Walter actually answered the other issue....

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

What does everyone think?  Are we ready to call this issue 'done'?

But plenty still remains.  I haven't had a chance to test 0.90 yet (my regular means of software transfer has gone missing at this time), but looking at 0.89 the rest of the bugs I've checked are still there.  And documentation maintenance hasn't got far with clearing up any issues either.

I haven't experimented much with in/out/inout on arrays in the last few versions, but it's something that needs clear defining at least.

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

And as for Phobos?

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

Well, if the documentation's anything to go by (which it probably isn't), then the holes seem to be still there.  For that matter, std.file could actually do with more than just a copy function, like set attributes and get/set timestamp.

OK, so number 2 should be an easy fix, and I finally figured out the esoteric reason behind 3.

So, if we're going to have a clear, clean, consistent and complete spec and a clear, clean, consistent and complete compiler to call 1.0, we'd better get a move on!

(I bet some issues would be easy fixes if only the open source included the connections between the front-end and std.internal....)

Stewart.

-- 
My e-mail is valid but not my primary mailbox, aside from its being the unfortunate victim of intensive mail-bombing at the moment.  Please keep replies on the 'group where everyone may benefit.

I don't mean to totally crush your spirit, but:

0.98
0.99
0.100
0.101

is possible.

BA

;)

Stewart Gordon wrote:
> Time is running out.  Or rather, version numbers are running out.  (That is, unless my suggestion of 0.01 increments from now on is implemented.)
> 
> So, it's time to look at what's left before we can sensibly finally cross over the bridge to 1.0.
> 
> http://www.wikiservice.at/wiki4d/wiki.cgi?PendingPeeves
> 
> Since I started it, it has grown a bit, but has shrunk only in one or two little bits.  OK, so AssertError has finally been fixed, and with now works on structs.  As for context-free grammar, C-style casts have been deprecated, and Walter actually answered the other issue....
> 
> http://www.digitalmars.com/drn-bin/wwwnews?D/27688
> 
> What does everyone think?  Are we ready to call this issue 'done'?
> 
> But plenty still remains.  I haven't had a chance to test 0.90 yet (my regular means of software transfer has gone missing at this time), but looking at 0.89 the rest of the bugs I've checked are still there.  And documentation maintenance hasn't got far with clearing up any issues either.
> 
> I haven't experimented much with in/out/inout on arrays in the last few versions, but it's something that needs clear defining at least.
> 
> http://www.digitalmars.com/drn-bin/wwwnews?D/27600
> 
> And as for Phobos?
> 
> http://www.digitalmars.com/drn-bin/wwwnews?D/27490
> 
> Well, if the documentation's anything to go by (which it probably isn't), then the holes seem to be still there.  For that matter, std.file could actually do with more than just a copy function, like set attributes and get/set timestamp.
> 
> OK, so number 2 should be an easy fix, and I finally figured out the esoteric reason behind 3.
> 
> So, if we're going to have a clear, clean, consistent and complete spec and a clear, clean, consistent and complete compiler to call 1.0, we'd better get a move on!
> 
> (I bet some issues would be easy fixes if only the open source included the connections between the front-end and std.internal....)
> 
> Stewart.
> 

> Time is running out.  Or rather, version numbers are running out.  (That is, unless my suggestion of 0.01 increments from now on is implemented.)

I don't get why everyone keeps saying this. Version numbers are not floating points. v0.90 is the 90th (or 91st, depending on how you calculate it) minor revision to the zeroth major revision. There can be an unlimited number of minor versions, so we could easily have version 0.101 or, pessimistically, 0.1001.

I'm sure Walter's hoping to bump the major version before we hit the 100th minor version, but there's nothing to say that this _must_ be so.

And here I was looking forward to June 6th being D-day. (60th anniversary this
year.)

In article <c90vea$2s0$1@digitaldaemon.com>, Matthew says...
>
>> Time is running out.  Or rather, version numbers are running out.  (That is, unless my suggestion of 0.01 increments from now on is implemented.)
>
>I don't get why everyone keeps saying this. Version numbers are not floating points. v0.90 is the 90th (or 91st, depending on how you calculate it) minor revision to the zeroth major revision. There can be an unlimited number of minor versions, so we could easily have version 0.101 or, pessimistically, 0.1001.
>
>I'm sure Walter's hoping to bump the major version before we hit the 100th minor version, but there's nothing to say that this _must_ be so.

Juan C wrote:
> And here I was looking forward to June 6th being D-day. (60th anniversary this
> year.)

We could still celebrate D-Day by particapting in ICFP 2004:
Contest start: Friday June 4, 2004 - 16:00 UTC (12:00 noon EDT)
Contest finish: Monday June 7, 2004 - 16:00 UTC (12:00 noon EDT)

http://www.cis.upenn.edu/proj/plclub/contest/dates.php

Just an idea.
http://www.dsource.org/forums/viewtopic.php?t=141

> 
> In article <c90vea$2s0$1@digitaldaemon.com>, Matthew says...
> 
>>>Time is running out.  Or rather, version numbers are running out.  (That
>>>is, unless my suggestion of 0.01 increments from now on is implemented.)
>>
>>I don't get why everyone keeps saying this. Version numbers are not floating
>>points. v0.90 is the 90th (or 91st, depending on how you calculate it) minor
>>revision to the zeroth major revision. There can be an unlimited number of minor
>>versions, so we could easily have version 0.101 or, pessimistically, 0.1001.
>>
>>I'm sure Walter's hoping to bump the major version before we hit the 100th minor
>>version, but there's nothing to say that this _must_ be so.

-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/

Matthew wrote:

>> Time is running out.  Or rather, version numbers are running out. (That is, unless my suggestion of 0.01 increments from now on is implemented.)
> 
> I don't get why everyone keeps saying this. Version numbers are not floating points.
<snip>

There is no rule that everyone follows.  Some developers number their versions with decimal numbers.  Others use hierarchical section numbers.

For example, Windows 3.1 was called Windows 3.10 in some paperwork.  It was followed by Windows 3.11, which IINM meant the 1st very minor version of the 1st minor version of the 3rd major version.

OTOH, users of the section numbering system sometimes follow 2.9 with 2.10.  This is confusing, as there will always be people who assume that they are decimal numbers, and hence that 2.10 comes before 2.2, and if they've heard of both 2.1 and 2.10 then that they refer to the same thing.

To be sure, you'd need either to look at the dates, or an authoritative source to tell you whether this particular 2.10 is pronounced "two point one zero" or "two dot ten".

The only way to achieve unambiguity is to stick to one number of digits below a given major version number.  If you then find that you needed more minor version numbers than you had allocated, you can add a second level perhaps as letters or a second decimal point (or section level delimiter, whatever).  Several developers do use three-level versioning like this, but most of them seem to stick to one digit at each level.

Stewart.

-- 
My e-mail is valid but not my primary mailbox, aside from its being the
unfortunate victim of intensive mail-bombing at the moment.  Please keep
replies on the 'group where everyone may benefit.

"Stewart Gordon" <smjg_1998@yahoo.com> wrote in message news:c91pdm$19k5$1@digitaldaemon.com...
> Matthew wrote:
>
> >> Time is running out.  Or rather, version numbers are running out. (That is, unless my suggestion of 0.01 increments from now on is implemented.)
> >
> > I don't get why everyone keeps saying this. Version numbers are not floating points.
> <snip>
>
> There is no rule that everyone follows.  Some developers number their versions with decimal numbers.  Others use hierarchical section numbers.
>
> For example, Windows 3.1 was called Windows 3.10 in some paperwork.  It was followed by Windows 3.11, which IINM meant the 1st very minor version of the 1st minor version of the 3rd major version.

Other than this case, which I don't believe serves your argument because I don't think there was any logic to it at all, I can't think of a single case where your floating-point version numbering is used.

> OTOH, users of the section numbering system sometimes follow 2.9 with 2.10.  This is confusing, as there will always be people who assume that they are decimal numbers, and hence that 2.10 comes before 2.2, and if they've heard of both 2.1 and 2.10 then that they refer to the same thing.
>
> To be sure, you'd need either to look at the dates, or an authoritative source to tell you whether this particular 2.10 is pronounced "two point one zero" or "two dot ten".
>
> The only way to achieve unambiguity is to stick to one number of digits below a given major version number.  If you then find that you needed more minor version numbers than you had allocated, you can add a second level perhaps as letters or a second decimal point (or section level delimiter, whatever).  Several developers do use three-level versioning like this, but most of them seem to stick to one digit at each level.

I use a four part versioning scheme.

For binaries, it is major.minor.revision.build, and for source it is major.minor.revision.edit (+ I always record the date of change).

Major are drastic changes, requiring wholesale rewriting of client code. This is
1-based
Minor are functionality additions, or significant changes that may require
recompilation/relinking. This is 0-based
Revision are bug fixes which do not require rewriting any client code / relinking
any client binary, but which will obviously result in changed behaviour, since it
is corrected. This is 1-based
Build is a number representing the Nth build. N is ever incrementing, and is
indepenting of the other three levels
Edit is a number representing the Nth edit. N is ever incrementing, and is
indepenting of the other three levels.

Naturally I have automated tools to help managing these things for both bin & source, although they're not anything brilliant.

I've used these schemes for many years now, and find them very useful and easily workable.

I guess that whole discussion about versioning schemes has to be sorted out:

* From version 1.0 on, the language should be considered stable, and a clear versioning scheme is needed to show major/minor/release/bugfix version changes.

* Currently, the whole language is in the beta stage where a clear versioning scheme would be broken every once in a while anyway. Versions should increase and should be unique to identify a certain version when talking about bugs etc. Beyond that it is pure psychology: Usually low numbers show very early alpha releases, higher number show the level of confidence that the developers have. Often, this gives an estimate on how far you are away from the first "stable" release. Such an estimate is very hard to make at the moment, so I wouldn't care about that kind of psychology at all. Of course, when people see 0.99, they will think "Hey, stable is right around the corner, but hey: let them think. As soon as 0.100 is out, they will know what is meant.

Once it is really going for a first stable release, I would rather go for 1.0beta1... and later 1.0rc1... to show that it is time for the last fixes.

"Norbert Nemec" <Norbert.Nemec@gmx.de> wrote in message news:c928e3$1uv2$1@digitaldaemon.com...
> I guess that whole discussion about versioning schemes has to be sorted out:
>
> * From version 1.0 on, the language should be considered stable, and a clear versioning scheme is needed to show major/minor/release/bugfix version changes.

Agreed.

> * Currently, the whole language is in the beta stage where a clear versioning scheme would be broken every once in a while anyway. Versions should increase and should be unique to identify a certain version when talking about bugs etc. Beyond that it is pure psychology: Usually low numbers show very early alpha releases, higher number show the level of confidence that the developers have. Often, this gives an estimate on how far you are away from the first "stable" release. Such an estimate is very hard to make at the moment, so I wouldn't care about that kind of psychology at all. Of course, when people see 0.99, they will think "Hey, stable is right around the corner, but hey: let them think. As soon as 0.100 is out, they will know what is meant.

Agreed


> Once it is really going for a first stable release, I would rather go for 1.0beta1... and later 1.0rc1... to show that it is time for the last fixes.

Agreed

Stewart Gordon wrote:

> Time is running out.  Or rather, version numbers are running out.  (That is, unless my suggestion of 0.01 increments from now on is implemented.)
<snip>

Oops ... how did that one slip past?  We've been going in 0.01 increments all along.  It's 0.001 increments we need.

But as said, it does depend on whether DMD version numbers are decimal.  But even if 0.100 follows 0.99, it'll appear to go up in 0.001 from then on.

Stewart.

-- 
My e-mail is valid but not my primary mailbox, aside from its being the unfortunate victim of intensive mail-bombing at the moment.  Please keep replies on the 'group where everyone may benefit.