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?

-- 
Shriramana Sharma, Penguin #395953
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... -- Shriramana Sharma, Penguin #395953
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! -- Shriramana Sharma, Penguin #395953
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 -- Shriramana Sharma, Penguin #395953
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... -- Shriramana Sharma, Penguin #395953
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... -- Shriramana Sharma, Penguin #395953
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. -- Shriramana Sharma, Penguin #395953
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. -- Shriramana Sharma, Penguin #395953
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 -- Shriramana Sharma, Penguin #395953
Oct 17 2015