www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - 0 in version number?

reply Shriramana Sharma <samjnaa_dont_spam_me gmail.com> writes:
I always wondered why DMD releases have a 0 in their minor version number -- 
surely 2.068 is the same as 2.68? Why then retain the zero?

--
Oct 16 2015
next sibling parent extrawurst <stephan extrawurst.org> writes:
On Friday, 16 October 2015 at 15:20:54 UTC, Shriramana Sharma 
wrote:

 I always wondered why DMD releases have a 0 in their minor 
 version number -- surely 2.068 is the same as 2.68? Why then 
 retain the zero?


Yeah consistent SemVer would be better.
Oct 16 2015
prev sibling next sibling parent Kagamin <spam here.lot> writes:
Probably for simple sorting so that 2.68 doesn't come before 
2.100.
Oct 16 2015
prev sibling next sibling parent reply Gary Willoughby <dev nomad.so> writes:
On Friday, 16 October 2015 at 15:20:54 UTC, Shriramana Sharma 
wrote:

 I always wondered why DMD releases have a 0 in their minor 
 version number -- surely 2.068 is the same as 2.68? Why then 
 retain the zero?


We keep trying to get people to understand the importance of a 
sane version scheme but it always falls on deaf ears. Even Walter 
considers this bikeshedding.

http://forum.dlang.org/post/ocjeghrkfkpjkvbxrzva forum.dlang.org
Oct 16 2015
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, 16 October 2015 at 16:44:19 UTC, Gary Willoughby wrote:

 On Friday, 16 October 2015 at 15:20:54 UTC, Shriramana Sharma 
 wrote:

 I always wondered why DMD releases have a 0 in their minor 
 version number -- surely 2.068 is the same as 2.68? Why then 
 retain the zero?


 We keep trying to get people to understand the importance of a 
 sane version scheme but it always falls on deaf ears. Even 
 Walter considers this bikeshedding.

 http://forum.dlang.org/post/ocjeghrkfkpjkvbxrzva forum.dlang.org


How is whether there's a 0 before the 68 anything but 
bikeshedding? It's the same number either way, it sorts better 
as-is, and it would be inconsistent of us to change now. Changing 
how the overall numbering scheme works might make sense, but 
simply removing the 0 wouldn't gain us anything as far as I can 
see.

- Jonathan M Davis
Oct 16 2015
parent reply Gary Willoughby <dev nomad.so> writes:
On Friday, 16 October 2015 at 17:58:27 UTC, Jonathan M Davis 
wrote:

 How is whether there's a 0 before the 68 anything but 
 bikeshedding? It's the same number either way, it sorts better 
 as-is, and it would be inconsistent of us to change now. 
 Changing how the overall numbering scheme works might make 
 sense, but simply removing the 0 wouldn't gain us anything as 
 far as I can see.

 - Jonathan M Davis


How? Let me explain.

Removing a zero is not what this is about. What we are talking 
about is marketing.

For D to be successful, to grow in users and respect, it has to 
accept that certain things must be done. It must appear to be 
part of the gang.

The versioning system that D uses is a reflection of the product 
as a whole. It's the same as the website and the tooling, etc. 
We, i.e. the D community, are using a version scheme no-one else 
uses. It confuses everyone who tries to understand it. For 
example, no one understands why there is a zero there. No-one 
understands why we are at a minor version of 68. Look at the 
version numbers of popular languages and then look at D. D is the 
odd one out!

D is full of these little details that are unfinished and 
strange. This is not the only reason, but it contributes to why D 
is not taken seriously. During a dconf talk where Andrie said 
(paraphrasing from his 2013 Quo Vadis talk?) to be a player we 
have to do what the big boys do. Well that totally went out the 
window immediately after the conference. Because every suggestion 
made to follow suit of the big boys always ends in cries of 
bikeshedding, it's unnecessary, etc. It's not unnecessary, it's 
what developers expect from professional management of a language.

Updating the version scheme to be more standardised and strict 
will give D more cachet. It will result more trust in the overall 
product.

At this stage it's all about publicity and marketing. If Walter 
and Andrei don't understand this, the foundation is going nowhere.
Oct 16 2015
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, 16 October 2015 at 22:44:15 UTC, Gary Willoughby wrote:

 On Friday, 16 October 2015 at 17:58:27 UTC, Jonathan M Davis 
 wrote:

 How is whether there's a 0 before the 68 anything but 
 bikeshedding? It's the same number either way, it sorts better 
 as-is, and it would be inconsistent of us to change now. 
 Changing how the overall numbering scheme works might make 
 sense, but simply removing the 0 wouldn't gain us anything as 
 far as I can see.

 - Jonathan M Davis


 How? Let me explain.

 Removing a zero is not what this is about. What we are talking 
 about is marketing.


[snip]

Fine. You think that making dmd's versioning be something more 
standard would help the community and its PR. And maybe it would. 
But simply removing the 0 doesn't do that. The whole versioning 
scheme would need to be changed. Even if discussing the 
versioning scheme isn't bikeshedding, simply arguing over whether 
the 0 should be there or not _is_ bikeshedding.

- Jonathan M Davis
Oct 16 2015
parent reply Israel <tl12000 live.com> writes:
On Friday, 16 October 2015 at 22:54:11 UTC, Jonathan M Davis 
wrote:

 On Friday, 16 October 2015 at 22:44:15 UTC, Gary Willoughby 
 wrote:

 On Friday, 16 October 2015 at 17:58:27 UTC, Jonathan M Davis 
 wrote:

 How is whether there's a 0 before the 68 anything but 
 bikeshedding? It's the same number either way, it sorts 
 better as-is, and it would be inconsistent of us to change 
 now. Changing how the overall numbering scheme works might 
 make sense, but simply removing the 0 wouldn't gain us 
 anything as far as I can see.

 - Jonathan M Davis


 How? Let me explain.

 Removing a zero is not what this is about. What we are talking 
 about is marketing.


 [snip]

 Fine. You think that making dmd's versioning be something more 
 standard would help the community and its PR. And maybe it 
 would. But simply removing the 0 doesn't do that. The whole 
 versioning scheme would need to be changed. Even if discussing 
 the versioning scheme isn't bikeshedding, simply arguing over 
 whether the 0 should be there or not _is_ bikeshedding.

 - Jonathan M Davis


Well sure, removing the 0 wouldnt cut it but at least 
incrementing it would make D seem more consistent across the 
board. 2.069 seems like D is all weirded out.

Maybe incrementing the version number like 2.070, 2.080, 2.100, 
2.120, 2.125, 2.135, would make ALOT more sense.
Oct 16 2015
parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, 17 October 2015 at 02:11:42 UTC, Israel wrote:

 Well sure, removing the 0 wouldnt cut it but at least 
 incrementing it would make D seem more consistent across the 
 board. 2.069 seems like D is all weirded out.

 Maybe incrementing the version number like 2.070, 2.080, 2.100, 
 2.120, 2.125, 2.135, would make ALOT more sense.


I don't see how. The number is jumping all over the place. I 
think that it's pretty clear that the first 0 in 2.069.0 is a 
placeholder so that digits don't have to be added when it hits 
2.100.x. That's done all the time with file names, even if it's 
less common with version numbers.

Regardless, I really do think that talking about messing with 
that 0 is total bikeshedding. If we decide that we want to go to 
a different versioning scheme for whatever reason, then we'd end 
up with something different, and maybe it wouldn't have that 0, 
but simply removing that zero really doesn't change anything 
except that it makes our version numbers less consistent.

In any case, I have a lot better things to do than discuss 
removing a 0 from the version number just because it's less 
common to do version numbers that way. Discussing a solid 
proposal on a different versioning scheme along with whatever 
release process would go with it would be one thing, but talking 
about an extra 0 in the version number? I waste too much time 
talking here rather than coding as it is. I probably shouldn't 
have commented in this thread in the first place.

- Jonathan M Davis
Oct 16 2015
prev sibling next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Fri, Oct 16, 2015 at 10:44:13PM +0000, Gary Willoughby via Digitalmars-d
wrote:

 On Friday, 16 October 2015 at 17:58:27 UTC, Jonathan M Davis wrote:

How is whether there's a 0 before the 68 anything but bikeshedding?
It's the same number either way, it sorts better as-is, and it would
be inconsistent of us to change now. Changing how the overall
numbering scheme works might make sense, but simply removing the 0
wouldn't gain us anything as far as I can see.

- Jonathan M Davis


 
 How? Let me explain.
 
 Removing a zero is not what this is about. What we are talking about
 is marketing.
 
 For D to be successful, to grow in users and respect, it has to accept
 that certain things must be done. It must appear to be part of the
 gang.
 
 The versioning system that D uses is a reflection of the product as a
 whole.  It's the same as the website and the tooling, etc. We, i.e.
 the D community, are using a version scheme no-one else uses. It
 confuses everyone who tries to understand it. For example, no one
 understands why there is a zero there.  No-one understands why we are
 at a minor version of 68. Look at the version numbers of popular
 languages and then look at D. D is the odd one out!


[...]

I do not speak for any of the core D devs, but ... I never understood
this fixation on conformity.  Is there concrete, non-anecdotal evidence
for people turning away from D because it has "strange" version numbers?
That seems an awfully poor and irrational excuse to reject a language.
You may as well recommend that we should avoid version numbers
containing 5, 13, and 666 because it might turn away superstitious
potential users.  How does that have anything to do with *real*
marketing?

On the contrary, the accepted wisdom is that *differentiating* your
product is generally a wiser business decision than conforming
willy-nilly to your competitors.

I can see a reason for adopting a *consistent* and *predictable*
versioning scheme -- it lets people know what's a stable release, what's
an interim release, what's a major change, what's a minor change, etc.,
and is useful for migration planning and such.  *That* I consider a good
marketing strategy.  But I don't understand what's with the fixation
that it must be *this* particular scheme with *this* particular set of
numbers, as if somehow the fact that the Big Boys, whoever they are,
chose some particular versioning scheme, magically endows that scheme
with miraculous marketing properties.

If we were starting from scratch, I could see the rationale for adopting
a "standard" versioning scheme... but why now, so late into the game,
and why version numbers, of all things, when there are far more
important matters at hand?

Not to mention, if you want to talk about the truly Big Boys, even
Windows doesn't follow any of the proposed versioning schemes (I mean,
what's up with 3.0 -> 3.1 -> 95 -> 98 -> 2000 -> XP -> 7 -> 8 -> 9... ?
That doesn't even follow any logical numerical ordering!), yet you have
to admit its marketing is far more successful than D can probably dream
of being. Does that mean that we should change D's versioning scheme
every 5 years in order to remain successful?


T

-- 
Nothing in the world is more distasteful to a man than to take the path that
leads to himself. -- Herman Hesse
Oct 16 2015
next sibling parent Shriramana Sharma <samjnaa_dont_spam_me gmail.com> writes:
H. S. Teoh via Digitalmars-d wrote:


 Windows doesn't follow any of the proposed versioning schemes (I mean,
 what's up with 3.0 -> 3.1 -> 95 -> 98 -> 2000 -> XP -> 7 -> 8 -> 9... ?


Heh -- nice point. But they market the visuals and the interface, not the 
version numbers. Nevertheless, lots of questions turn up on forums about the 
version numbers – like actually there isn't a Windows 9 (unlike you hastily 
mentioned above), is there?

I agree that D should have better marketing and hope the new Foundation will 
do more in this regard, but I don't see any serious *detrimental* effect of 
the current numbering scheme on the marketing. But it does seem somewhat 
*unprofessional* to have a meaningless zero therein. I was curious about it 
and more people (potential future users) are likely to have the same 
question. And you want people spending time using the language in actual 
programming, not writing forum posts asking why there's a zero (and replying 
to it)...

And I don't think this is the kind of thing that is supposed to stand out 
about D. "What, D? Oh you mean the language with the strange versioning 
system?"... Nah.

TeX (and MetaFont) have a strange versioning system, but that's not what it 
is known for, nor what it is marketed for... And people don't think it's 
unprofessional because while it is non-standard, it has a mathematical 
beauty to it, which the current 0 doesn't.

As to including the "0" for making it easier to parse, with all of D's power 
and syntactic expressiveness, are we saying that the 0 is there just so we 
can use plain ol' strcmp to compare existing 2.068 against a potential 
future 2.100? Aw come on...

Finally, +1 for having the version numbers somehow reflect the stability and 
deprecation and stuff. semver is great, and meaningful. IIUC that system, we 
should make D something like:

2.x.y.z

where we only deprecate/break API when we change x, and do only bugfixes in 
z releases. Qt is an example of a great and *huge* and *successful* project 
which follows a very strict versioning system.

I seriously think making a sane versioning scheme will help adoption of D in 
the marketplace.

That said, we should probably already throw out the initial 2. too...

--
Oct 16 2015
prev sibling next sibling parent reply Gary Willoughby <dev nomad.so> writes:
On Friday, 16 October 2015 at 23:23:15 UTC, H. S. Teoh wrote:

 Not to mention, if you want to talk about the truly Big Boys, 
 even Windows doesn't follow any of the proposed versioning 
 schemes (I mean, what's up with 3.0 -> 3.1 -> 95 -> 98 -> 2000 
 -> XP -> 7 -> 8 -> 9... ? That doesn't even follow any logical 
 numerical ordering!), yet you have to admit its marketing is 
 far more successful than D can probably dream of being.


This is wrong. Microsoft follows a very strict versioning system. 
The list you are referring to above are the marketing *names* of 
the operating systems, not the versions.

https://msdn.microsoft.com/en-gb/library/windows/desktop/ms724832(v=vs.85).aspx
https://en.wikipedia.org/wiki/List_of_Microsoft_Windows_versions
Oct 18 2015
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 10/18/2015 07:47 AM, Gary Willoughby wrote:

 On Friday, 16 October 2015 at 23:23:15 UTC, H. S. Teoh wrote:

 Not to mention, if you want to talk about the truly Big Boys, even
 Windows doesn't follow any of the proposed versioning schemes (I mean,
 what's up with 3.0 -> 3.1 -> 95 -> 98 -> 2000 -> XP -> 7 -> 8 -> 9...
 ? That doesn't even follow any logical numerical ordering!), yet you
 have to admit its marketing is far more successful than D can probably
 dream of being.


 This is wrong. Microsoft follows a very strict versioning system. The
 list you are referring to above are the marketing *names* of the
 operating systems, not the versions.

 https://msdn.microsoft.com/en-gb/library/windows/desktop/ms724832(v=vs.85).aspx

 https://en.wikipedia.org/wiki/List_of_Microsoft_Windows_versions


That's entirely irrelevent since nearly nobody ever hears, uses, or 
knows about those (essentially) internal version numbers.
Oct 19 2015
parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Mon, Oct 19, 2015 at 10:49:25AM -0400, Nick Sabalausky via Digitalmars-d
wrote:

 On 10/18/2015 07:47 AM, Gary Willoughby wrote:

On Friday, 16 October 2015 at 23:23:15 UTC, H. S. Teoh wrote:

Not to mention, if you want to talk about the truly Big Boys, even
Windows doesn't follow any of the proposed versioning schemes (I
mean, what's up with 3.0 -> 3.1 -> 95 -> 98 -> 2000 -> XP -> 7 -> 8
-> 9...  ? That doesn't even follow any logical numerical
ordering!), yet you have to admit its marketing is far more
successful than D can probably dream of being.


This is wrong. Microsoft follows a very strict versioning system. The
list you are referring to above are the marketing *names* of the
operating systems, not the versions.

https://msdn.microsoft.com/en-gb/library/windows/desktop/ms724832(v=vs.85).aspx

https://en.wikipedia.org/wiki/List_of_Microsoft_Windows_versions


 
 That's entirely irrelevent since nearly nobody ever hears, uses, or
 knows about those (essentially) internal version numbers.


Not to mention, even for those who *do* know about these internal
version numbers, talking about NT 6.2 vs. NT 6.3 is the best way to get
blank stares from your average audience, who will have no idea what
you're talking about.

Besides, we were talking about marketing. As far as marketing is
concerned, the "marketing names" of Windows are what people see and
know, not the internal version numbers, which have nothing to do with
marketing.


T

-- 
MAS = Mana Ada Sistem?
Oct 19 2015
prev sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 10/16/2015 07:19 PM, H. S. Teoh via Digitalmars-d wrote:

 I do not speak for any of the core D devs, but ... I never understood
 this fixation on conformity.  Is there concrete, non-anecdotal evidence
 for people turning away from D because it has "strange" version numbers?
 That seems an awfully poor and irrational excuse to reject a language.
 You may as well recommend that we should avoid version numbers
 containing 5, 13, and 666 because it might turn away superstitious
 potential users.  How does that have anything to do with *real*
 marketing?

 On the contrary, the accepted wisdom is that *differentiating* your
 product is generally a wiser business decision than conforming
 willy-nilly to your competitors.

 I can see a reason for adopting a *consistent* and *predictable*
 versioning scheme -- it lets people know what's a stable release, what's
 an interim release, what's a major change, what's a minor change, etc.,
 and is useful for migration planning and such.  *That* I consider a good
 marketing strategy.  But I don't understand what's with the fixation
 that it must be *this* particular scheme with *this* particular set of
 numbers, as if somehow the fact that the Big Boys, whoever they are,
 chose some particular versioning scheme, magically endows that scheme
 with miraculous marketing properties.

 If we were starting from scratch, I could see the rationale for adopting
 a "standard" versioning scheme... but why now, so late into the game,
 and why version numbers, of all things, when there are far more
 important matters at hand?


Yea, +1 here


 Not to mention, if you want to talk about the truly Big Boys, even
 Windows doesn't follow any of the proposed versioning schemes (I mean,
 what's up with 3.0 -> 3.1 -> 95 -> 98 -> 2000 -> XP -> 7 -> 8 -> 9... ?


Fixed:

... -> 3.1 -> 95 -> 97^H^H98 -> Me -> XP -> Vista -> 7 -> 8 -> 10
           \-> 4 -> 2000 -> Server 2003 -> ...


 That doesn't even follow any logical numerical ordering!), yet you have
 to admit its marketing is far more successful than D can probably dream
 of being. Does that mean that we should change D's versioning scheme
 every 5 years in order to remain successful?


If we really want to be hip and cool we should follow the brilliant 
versioning schemes from Debian and Apple:

Woody -> Sarge -> Etch -> Lenny -> Squeeze -> Wheezy -> Jessie -> Stretch

Puma -> Jaguar -> Panther -> ... -> Lion -> Mountain Lion -> Mavericks 
-> Yosemite -> El Capitan

For bonus "cool" points, we can force everyone to memorize two 
completely *separate* versioning schemes for the same product, one 
numerical and one unordered and nonsensical, and make everyone memorize 
how each of the two version names for each release line up with each other.

SemVer is very good. But aside from that, all this worrying over version 
numbers, and changing DMD's scheme, is all just "Fire and Motion": 
http://www.joelonsoftware.com/articles/fog0000000339.html
Oct 19 2015
next sibling parent Kagamin <spam here.lot> writes:
On Monday, 19 October 2015 at 14:37:37 UTC, Nick Sabalausky wrote:

 ... -> 3.1 -> 95 -> 97^H^H98 -> Me -> XP -> Vista -> 7 -> 8 -> 
 10
           \-> 4 -> 2000 -> Server 2003 -> ...


Though, NT family is not a branch from DOS family, but a separate 
OS and it comes in pairs client/server editions, so not really an 
evolution of 2000, which came paired too, 8.1 is a distinct 
release.
Oct 19 2015
prev sibling parent reply BusPassenger <bp nowhere.th> writes:
On Monday, 19 October 2015 at 14:37:37 UTC, Nick Sabalausky wrote:

 SemVer is very good.


No, it's not. It's "a bit" in the OSS field but in commercial 
software, this versionning scheme doesn't allow to make a big 
psychological hit when a new version is released. (1.9.9 -> 
2.0.0).

I even find that in OSS it tends to suck;

example 1/
Linux, Apper, list of versions for a package: it's not always 
that obvious to see which is the latest.

example 2/
A lot of OSS don't reach the 1.0.0 milestone. Even if the product 
has a good maturity (stable, production-ready) for the end user 
it still looks like an alpha thing.

Now let's talk about git + semVer. Let's say it's used to flag a 
particular sub-version: useless, because you can use the SHA 
already to checkout. The worst thing I've seen so far is someone 
who used to put a git tag with a semVer label for almost every 
commit.

Conclusion: I barely see where SemVer is good. It's just a way to 
do among the others. Since there's no particular rule about how 
to use it semVer can even become a cripple (example 2).
Oct 19 2015
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Monday, 19 October 2015 at 18:49:38 UTC, BusPassenger wrote:

 example 2/
 A lot of OSS don't reach the 1.0.0 milestone. Even if the 
 product has a good maturity (stable, production-ready) for the 
 end user it still looks like an alpha thing.


Version "0.y.z" is a strong indicator that the API may change 
without the previous version being maintained. Meaning, you are 
on your own as a developer.
Oct 19 2015
prev sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 10/19/2015 02:49 PM, BusPassenger wrote:

 On Monday, 19 October 2015 at 14:37:37 UTC, Nick Sabalausky wrote:

 SemVer is very good.


 but in commercial software,
 this versionning scheme doesn't allow to make a big psychological hit
 when a new version is released. (1.9.9 -> 2.0.0).


That's one of the awesome things about semantic versioning! No 
marketing-driven bullshitery. Just straight honest truth.
Oct 23 2015
prev sibling parent Ozan <ozan.sueel gmail.com> writes:
On Friday, 16 October 2015 at 22:44:15 UTC, Gary Willoughby wrote:

 On Friday, 16 October 2015 at 17:58:27 UTC, Jonathan M Davis 
 wrote:

 [...]


 How? Let me explain.

 [...]

 [...]


Great words! And today every success is somehow a result of 
marketing.
Oct 26 2015
prev sibling next sibling parent reply bitwise <bitwise.pvt gmail.com> writes:
On Friday, 16 October 2015 at 15:20:54 UTC, Shriramana Sharma 
wrote:

 I always wondered why DMD releases have a 0 in their minor 
 version number -- surely 2.068 is the same as 2.68? Why then 
 retain the zero?


If we just wait a bit, couldn't this just work itself out?

2.069
2.070
...
...
2.098
2.099
2.100 -> transition here, maintain sortability
2.1.01
2.1.02
2.1.03
....

     Bit
Oct 16 2015
parent reply Shriramana Sharma <samjnaa_dont_spam_me gmail.com> writes:
bitwise wrote:


 2.100 -> transition here, maintain sortability


Again, what's this about sortability? Raise your hands please whoever is 
using strcmp or the like to do sorting on D version numbers!

--
Oct 17 2015
parent reply Marc =?UTF-8?B?U2Now7x0eg==?= <schuetzm gmx.net> writes:
On Saturday, 17 October 2015 at 08:51:05 UTC, Shriramana Sharma 
wrote:

 bitwise wrote:


 2.100 -> transition here, maintain sortability


 Again, what's this about sortability? Raise your hands please 
 whoever is using strcmp or the like to do sorting on D version 
 numbers!


Sorting happens in many places where the sorting program is not 
aware that it's working with version numbers. Think of directory 
listings, for example.
Oct 17 2015
next sibling parent bitwise <bitwise.pvt gmail.com> writes:
On Saturday, 17 October 2015 at 11:44:31 UTC, Marc Schütz wrote:

 On Saturday, 17 October 2015 at 08:51:05 UTC, Shriramana Sharma 
 wrote:

 bitwise wrote:


 2.100 -> transition here, maintain sortability


 Again, what's this about sortability? Raise your hands please 
 whoever is using strcmp or the like to do sorting on D version 
 numbers!


 Sorting happens in many places where the sorting program is not 
 aware that it's working with version numbers. Think of 
 directory listings, for example.


Also, in your brain ;)

When you look at two version numbers next to each other, you have 
to be able to tell which one is larger.

2.1 > 2.099

     Bit
Oct 17 2015
prev sibling parent reply Shriramana Sharma <samjnaa_dont_spam_me gmail.com> writes:
Marc Schütz wrote:


 Sorting happens in many places where the sorting program is not
 aware that it's working with version numbers. Think of directory
 listings, for example.


$ cd /tmp/
$ touch f{1..20}
$ ls -v1
f1
f2
f3
f4
f5
f6
f7
f8
f9
f10
f11
f12
f13
f14
f15
f16
f17
f18
f19
f20

--
Oct 17 2015
next sibling parent reply bitwise <bitwise.pvt gmail.com> writes:
On Saturday, 17 October 2015 at 15:36:10 UTC, Shriramana Sharma 
wrote:

 Marc Schütz wrote:


 Sorting happens in many places where the sorting program is 
 not aware that it's working with version numbers. Think of 
 directory listings, for example.


 $ cd /tmp/
 $ touch f{1..20}
 $ ls -v1
 f1
 f2
 f3
 f4
 f5
 f6
 f7
 f8
 f9
 f10
 f11
 f12
 f13
 f14
 f15
 f16
 f17
 f18
 f19
 f20


touch f1.098
touch f1.099
touch f1.1.0
touch f1.1.1
ls
Oct 17 2015
next sibling parent reply Shriramana Sharma <samjnaa_dont_spam_me gmail.com> writes:
bitwise wrote:


 touch f1.098
 touch f1.099
 touch f1.1.0
 touch f1.1.1
 ls


Sorry don't understand what you are getting at...

--
Oct 17 2015
parent reply bitwise <bitwise.pvt gmail.com> writes:
On Sunday, 18 October 2015 at 02:26:22 UTC, Shriramana Sharma 
wrote:

 bitwise wrote:


 touch f1.098
 touch f1.099
 touch f1.1.0
 touch f1.1.1
 ls


 Sorry don't understand what you are getting at...


Not sure what you're getting at either.
Oct 17 2015
parent reply Shriramana Sharma <samjnaa_dont_spam_me gmail.com> writes:
bitwise wrote:


 Not sure what you're getting at either.


By `ls -v1` I was illustrating that directory listing utilities are capable 
of sorting numbers meaningfully, so there is no need for leading zeroes for 
*that* purpose...

--
Oct 17 2015
next sibling parent anonymous <anonymous example.com> writes:
On Sunday, October 18, 2015 05:09 AM, Shriramana Sharma wrote:


 By `ls -v1` I was illustrating that directory listing utilities are
 capable of sorting numbers meaningfully, so there is no need for leading
 zeroes for *that* purpose...


You only showed that ls can do it, and you need a special flag for it. 
That's not very conclusive.
Oct 18 2015
prev sibling parent bitwise <bitwise.pvt gmail.com> writes:
On Sunday, 18 October 2015 at 03:28:28 UTC, Shriramana Sharma 
wrote:

 bitwise wrote:


 Not sure what you're getting at either.


 By `ls -v1` I was illustrating that directory listing utilities 
 are capable of sorting numbers meaningfully, so there is no 
 need for leading zeroes for *that* purpose...


Ok, gotcha. My answer was a bit of a shot in the dark, but the 
point was that a transition to a more normal looking versioning 
system could be made at 2.1 without compromising the logical 
ordering of the version numbers.

Looking at semver.org though, it seems that the major version 
should be incremented for every version that's not backward 
compatible, which basically makes it impossible for D to conform 
to that versioning system at present. With rangification of 
phobos, the removal of std.stream, the endless supply of breaking 
DIPs, etc, D will be at 100.0.0 by next year.. ;)

      Bit
Oct 18 2015
prev sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Saturday, 17 October 2015 at 20:30:50 UTC, bitwise wrote:

 touch f1.098
 touch f1.099
 touch f1.1.0
 touch f1.1.1
 ls


ls|sort -g -t. -k2
Oct 19 2015
prev sibling parent reply Kagamin <spam here.lot> writes:
On Saturday, 17 October 2015 at 15:36:10 UTC, Shriramana Sharma 
wrote:

 Marc Schütz wrote:


 Sorting happens in many places where the sorting program is 
 not aware that it's working with version numbers. Think of 
 directory listings, for example.


 $ cd /tmp/
 $ touch f{1..20}
 $ ls -v1
 f1
 f2
 f3
 f4
 f5
 f6
 f7
 f8
 f9
 f10
 f11
 f12
 f13
 f14
 f15
 f16
 f17
 f18
 f19
 f20


$ ls -v1 | sort
Oct 19 2015
parent Shriramana Sharma <samjnaa_dont_spam_me gmail.com> writes:
Kagamin wrote:


 $ ls -v1 | sort


ls -v1 | sort -V

:-D

But there's still no good answer to the question why there should be a zero 
in 2.068.2; OTOH, I discovered that since the API is still unstable, 2.068 
should actually be 2.0.68.2 meaning 2nd bugfix release of the 68th minor 
release of the 0th major version i.e. unstable API of the 2nd version of the 
language.

--
Oct 20 2015
prev sibling parent reply Shriramana Sharma <samjnaa_dont_spam_me gmail.com> writes:
Shriramana Sharma wrote:


 I always wondered why DMD releases have a 0 in their minor version number
 -- surely 2.068 is the same as 2.68? Why then retain the zero?


BTW the Deb packages show the zero as a separate field in the SO versioning:

/usr/lib/x86_64-linux-gnu/libphobos2.so.0.68.2
/usr/lib/x86_64-linux-gnu/libphobos2.so.0.68

So what is that zero supposed to indicate now?!

Heh, it's actually sorta appropriate. Major versions zero are often used to 
indicate that the API is not yet stable and minor versions don't guarantee 
API stability. Since that's true for Phobos, where we don't have a stable 
versioning system yet, the zero as the major version number (ignoring the 
language version 2) is correct in a way, I guess.

--
Oct 17 2015
parent Shriramana Sharma <samjnaa_dont_spam_me gmail.com> writes:
Shriramana Sharma wrote:


 Major versions zero are often used to
 indicate that the API is not yet stable and minor versions don't guarantee
 API stability. Since that's true for Phobos, where we don't have a stable
 versioning system yet, the zero as the major version number (ignoring the
 language version 2) is correct in a way, I guess.


Looks like SemVer (http://semver.org/) already mentions this:

"""Major version zero (0.y.z) is for initial development. Anything may 
change at any time. The public API should not be considered stable."""

But "initial development", really!

https://wiki.qt.io/Qt-Version-Compatibility

--
Oct 17 2015