www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - With 0.1 of a version left to go, time to look at the pending peeves

reply Stewart Gordon <smjg_1998 yahoo.com> writes:
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.
May 25 2004
next sibling parent Brad Anderson <brad dsource.dot.org> writes:
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.
May 25 2004
prev sibling next sibling parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
 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.
May 25 2004
next sibling parent Juan C <Juan_member pathlink.com> writes:
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.
May 25 2004
prev sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
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.
May 26 2004
parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
"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.
May 26 2004
parent reply Norbert Nemec <Norbert.Nemec gmx.de> writes:
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.
May 26 2004
parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
"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
May 26 2004
prev sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
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.
May 27 2004
parent reply Helmut Leitner <helmut.leitner wikiservice.at> writes:
Stewart Gordon wrote:

 
 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.


There is another possibility that is less ugly.

Count 0.90, 0.901, 0.902 ... 0.999 and you
win another 90 revisions without break fp >.

-- 
Helmut Leitner    leitner hls.via.at
Graz, Austria   www.hls-software.com
May 27 2004
parent Stewart Gordon <smjg_1998 yahoo.com> writes:
Helmut Leitner wrote:

<snip>

 There is another possibility that is less ugly.
 
 Count 0.90, 0.901, 0.902 ... 0.999 and you
 win another 90 revisions without break fp >.


That's exactly what I meant in the first place.

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.
May 28 2004