www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Phobos version naming

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.com> writes:
I'd like to devise a robust version naming for Phobos. What is the best way?

Currently it's std.v2 but I'm unclear how it goes from there. By semver 
we'd go with std.v2_0_1 and so on.

Walter and others say it's better to have "std2" at top level instead of 
"std.v2" nested inside std. I confess I chose "std.v2" partially because 
it's easier to implement. But we can go either way. What would be best?
Nov 03 2021
next sibling parent reply Paul Backus <snarwin gmail.com> writes:
On Wednesday, 3 November 2021 at 15:37:05 UTC, Andrei 
Alexandrescu wrote:

 Currently it's std.v2 but I'm unclear how it goes from there. 
 By semver we'd go with std.v2_0_1 and so on.


This seems like a misuse of semver to me. Backwards-compatible 
bugfixes and additions to std.v2 can go directly into std.v2, 
just like they currently do for std. There is no need to create 
separate packages for every minor and patch increment.

If we really want to support users depending on a specific 
minor/patch release of Phobos other than the one shipped with 
their D toolchain, we should put Phobos on code.dlang.org.
Nov 03 2021
next sibling parent Alexandru Ermicioi <alexandru.ermicioi gmail.com> writes:
On Wednesday, 3 November 2021 at 16:29:20 UTC, Paul Backus wrote:

 On Wednesday, 3 November 2021 at 15:37:05 UTC, Andrei 
 Alexandrescu wrote:

 Currently it's std.v2 but I'm unclear how it goes from there. 
 By semver we'd go with std.v2_0_1 and so on.


 This seems like a misuse of semver to me. Backwards-compatible 
 bugfixes and additions to std.v2 can go directly into std.v2, 
 just like they currently do for std. There is no need to create 
 separate packages for every minor and patch increment.

 If we really want to support users depending on a specific 
 minor/patch release of Phobos other than the one shipped with 
 their D toolchain, we should put Phobos on code.dlang.org.


It could also be split into sub packages, this way it should be 
possible to pick up patched version of subpackage, if it is 
problematic to move entire phobos to newer version.

Best regards,
Alexandru.
Nov 03 2021
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.com> writes:
On 2021-11-03 12:29, Paul Backus wrote:

 On Wednesday, 3 November 2021 at 15:37:05 UTC, Andrei Alexandrescu wrote:

 Currently it's std.v2 but I'm unclear how it goes from there. By 
 semver we'd go with std.v2_0_1 and so on.


 
 This seems like a misuse of semver to me. Backwards-compatible bugfixes 
 and additions to std.v2 can go directly into std.v2, just like they 
 currently do for std. There is no need to create separate packages for 
 every minor and patch increment.
 
 If we really want to support users depending on a specific minor/patch 
 release of Phobos other than the one shipped with their D toolchain, we 
 should put Phobos on code.dlang.org.


OK, so the way to go is with std version naming is...?
Nov 03 2021
parent reply Paul Backus <snarwin gmail.com> writes:
On Wednesday, 3 November 2021 at 17:42:06 UTC, Andrei 
Alexandrescu wrote:

 On 2021-11-03 12:29, Paul Backus wrote:

 On Wednesday, 3 November 2021 at 15:37:05 UTC, Andrei 
 Alexandrescu wrote:

 Currently it's std.v2 but I'm unclear how it goes from there. 
 By semver we'd go with std.v2_0_1 and so on.


 
 This seems like a misuse of semver to me. Backwards-compatible 
 bugfixes and additions to std.v2 can go directly into std.v2, 
 just like they currently do for std. There is no need to 
 create separate packages for every minor and patch increment.
 
 If we really want to support users depending on a specific 
 minor/patch release of Phobos other than the one shipped with 
 their D toolchain, we should put Phobos on code.dlang.org.


 OK, so the way to go is with std version naming is...?


Having thought about this some more, I think there are two 
separate issues here: naming and distribution.

SemVer tells us how to do naming; i.e., how to refer to a 
particular release, like "1.0.0" or "2.0.1". I do not think we 
should abandon SemVer for naming.

However, SemVer does not tell us how to do distribution; i.e., 
how users can get access to a particular release. There are many 
possible choices we can make here:

* Ship every release with the official D distribution.
* Ship the latest release of each major version with the official 
D distribution.
* Ship every release on code.dlang.org.
* Ship some releases with the official D distribution and others 
on code.dlang.org.

Given that code.dlang.org already has infrastructure in place for 
distributing many releases of the same package, I think it makes 
sense to use it for at least some of Phobos's distribution, if 
not all of it. And my gut reaction is that shipping *every* 
release in the official D distribution would be too much--at the 
very least, new users should not be presented with dozens of 
standard-library releases to choose from right off the bat. So, 
the right answer is probably somewhere between those two extremes.
Nov 03 2021
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 04/11/2021 4:50 PM, Paul Backus wrote:

 Given that code.dlang.org already has infrastructure in place for 
 distributing many releases of the same package, I think it makes sense 
 to use it for at least some of Phobos's distribution, if not all of it. 
 And my gut reaction is that shipping *every* release in the official D 
 distribution would be too much--at the very least, new users should not 
 be presented with dozens of standard-library releases to choose from 
 right off the bat. So, the right answer is probably somewhere between 
 those two extremes.


Yeah I am well past the point of laughing about all of this versioning 
stuff.

Give us a dub package for anything that hasn't matured.

Once matured, it goes into Phobos.

Too much energy is being wasted on what should be a pretty streamlined 
process.
Nov 04 2021
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/4/21 8:04 AM, rikki cattermole wrote:

 
 On 04/11/2021 4:50 PM, Paul Backus wrote:

 Given that code.dlang.org already has infrastructure in place for 
 distributing many releases of the same package, I think it makes sense 
 to use it for at least some of Phobos's distribution, if not all of 
 it. And my gut reaction is that shipping *every* release in the 
 official D distribution would be too much--at the very least, new 
 users should not be presented with dozens of standard-library releases 
 to choose from right off the bat. So, the right answer is probably 
 somewhere between those two extremes.


 
 Yeah I am well past the point of laughing about all of this versioning 
 stuff.
 
 Give us a dub package for anything that hasn't matured.
 
 Once matured, it goes into Phobos.
 
 Too much energy is being wasted on what should be a pretty streamlined 
 process.


I don't think how to explain better that the mechanics of versioning are 
a different concern entirely than distribution.
Nov 04 2021
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.com> writes:
On 2021-11-04 8:04, rikki cattermole wrote:

 
 On 04/11/2021 4:50 PM, Paul Backus wrote:

 Given that code.dlang.org already has infrastructure in place for 
 distributing many releases of the same package, I think it makes sense 
 to use it for at least some of Phobos's distribution, if not all of 
 it. And my gut reaction is that shipping *every* release in the 
 official D distribution would be too much--at the very least, new 
 users should not be presented with dozens of standard-library releases 
 to choose from right off the bat. So, the right answer is probably 
 somewhere between those two extremes.


 
 Yeah I am well past the point of laughing about all of this versioning 
 stuff.
 
 Give us a dub package for anything that hasn't matured.
 
 Once matured, it goes into Phobos.
 
 Too much energy is being wasted on what should be a pretty streamlined 
 process.


I've said this a few times and I'll say it again in the hope it catches on:

The process of distributing versions of software and the process of 
coding and maintaining versions of software are distinct.
Nov 08 2021
prev sibling next sibling parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Wednesday, 3 November 2021 at 15:37:05 UTC, Andrei 
Alexandrescu wrote:

 I'd like to devise a robust version naming for Phobos. What is 
 the best way?

 Currently it's std.v2 but I'm unclear how it goes from there. 
 By semver we'd go with std.v2_0_1 and so on.

 Walter and others say it's better to have "std2" at top level 
 instead of "std.v2" nested inside std. I confess I chose 
 "std.v2" partially because it's easier to implement. But we can 
 go either way. What would be best?


I would vote for having it at the same level. Regarding versions, 
how do other languages do it?
Nov 03 2021
parent reply harakim <harakim gmail.com> writes:
On Wednesday, 3 November 2021 at 16:46:39 UTC, Imperatorn wrote:

 On Wednesday, 3 November 2021 at 15:37:05 UTC, Andrei 
 Alexandrescu wrote:

 I'd like to devise a robust version naming for Phobos. What is 
 the best way?

 Currently it's std.v2 but I'm unclear how it goes from there. 
 By semver we'd go with std.v2_0_1 and so on.

 Walter and others say it's better to have "std2" at top level 
 instead of "std.v2" nested inside std. I confess I chose 
 "std.v2" partially because it's easier to implement. But we 
 can go either way. What would be best?


 I would vote for having it at the same level. Regarding 
 versions, how do other languages do it?


The more I look into this, I think they just create a new 
incompatible version, like Python2 and Python3.
Nov 03 2021
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 3 November 2021 at 18:11:28 UTC, harakim wrote:

 The more I look into this, I think they just create a new 
 incompatible version, like Python2 and Python3.


Yes, but not Python.

Python had a forward-compatible system library called future and 
a third party library called six that provided Python3 transition 
code. I had a template for Python2 that did the future 
compatibility imports, so when I transitioned to Python3 I just 
had to remove that line for the most part. :-) Python3 transition 
was painless for me.
Nov 03 2021
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.com> writes:
On 2021-11-03 11:37, Andrei Alexandrescu wrote:

 I'd like to devise a robust version naming for Phobos. What is the best 
 way?
 
 Currently it's std.v2 but I'm unclear how it goes from there. By semver 
 we'd go with std.v2_0_1 and so on.
 
 Walter and others say it's better to have "std2" at top level instead of 
 "std.v2" nested inside std. I confess I chose "std.v2" partially because 
 it's easier to implement. But we can go either way. What would be best?


Turns out switching names around is easy:

https://github.com/dlang/phobos/pull/8309/commits/5c6d9ba3aef59878b2b97c2464a1616d5dfce04b
Nov 03 2021
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.com> writes:
On 2021-11-03 11:37, Andrei Alexandrescu wrote:

 I'd like to devise a robust version naming for Phobos. What is the best 
 way?
 
 Currently it's std.v2 but I'm unclear how it goes from there. By semver 
 we'd go with std.v2_0_1 and so on.
 
 Walter and others say it's better to have "std2" at top level instead of 
 "std.v2" nested inside std. I confess I chose "std.v2" partially because 
 it's easier to implement. But we can go either way. What would be best?
 


One thought; we could call version actual names, like Ubuntu and OSX do. 
The version numbers will be a minor detail in the documentation.
Nov 03 2021
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 3 November 2021 at 19:30:13 UTC, Andrei 
Alexandrescu wrote:

 One thought; we could call version actual names, like Ubuntu 
 and OSX do. The version numbers will be a minor detail in the 
 documentation.


So you have "phobos", "deimos", then what?
Nov 03 2021
parent reply David Gileadi <gileadisNOSPM gmail.com> writes:
On 11/3/21 12:32 PM, Ola Fosheim Grøstad wrote:

 On Wednesday, 3 November 2021 at 19:30:13 UTC, Andrei Alexandrescu wrote:

 One thought; we could call version actual names, like Ubuntu and OSX 
 do. The version numbers will be a minor detail in the documentation.


 
 So you have "phobos", "deimos", then what?


But of course: Dejah Thoris, John Carter, Carthoris, Tara, Llana...

Bikeshed aside, named library versions may be more memorable but they 
have the downside that it's much harder to see two names and know which 
one is newer and/or current.
Nov 03 2021
next sibling parent reply Adam D Ruppe <destructionator gmail.com> writes:
On Wednesday, 3 November 2021 at 19:40:30 UTC, David Gileadi 
wrote:

 Bikeshed aside, named library versions may be more memorable 
 but they have the downside that it's much harder to see two 
 names and know which one is newer and/or current.


Yeah, the number is far more practical.
Nov 03 2021
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Nov 03, 2021 at 07:44:21PM +0000, Adam D Ruppe via Digitalmars-d wrote:

 On Wednesday, 3 November 2021 at 19:40:30 UTC, David Gileadi wrote:

 Bikeshed aside, named library versions may be more memorable but
 they have the downside that it's much harder to see two names and
 know which one is newer and/or current.


 
 Yeah, the number is far more practical.


I agree.  Debian GNU/Linux uses names for releases, and it's widely
hated.  Even people like me, who don't hate it, find it very confusing
because it's hard to tell which version is before or after which by
looking at some arbitrarily-chosen names.

Let's just stick with numbers please.


T

-- 
Give a man a fish, and he eats once. Teach a man to fish, and he will sit
forever.
Nov 03 2021
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.com> writes:
On 2021-11-03 15:44, Adam D Ruppe wrote:

 On Wednesday, 3 November 2021 at 19:40:30 UTC, David Gileadi wrote:

 Bikeshed aside, named library versions may be more memorable but they 
 have the downside that it's much harder to see two names and know 
 which one is newer and/or current.


 
 Yeah, the number is far more practical.


Prolly we could have both so people could use either "io" or "std2".
Nov 03 2021
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 3 November 2021 at 22:21:53 UTC, Andrei 
Alexandrescu wrote:

 Prolly we could have both so people could use either "io" or 
 "std2".


Oh, so you are leaving Mars and moving on to Jupiter? Good 
choice, [Jupiter has 79 moons (53 with 
names)](https://solarsystem.nasa.gov/moons/jupiter-moons/overview/?page=0&per_page=40&order=name+asc&search=&placeholder=Enter+moon+name&condition_1=9%3Aparent_id&condition_2=moon%3Abody_type%3Ailike).

Does leaving Mars (D2) and entering an orbit around Jupiter mean 
we will get D3 too?
Nov 03 2021
prev sibling parent reply Adam Ruppe <destructionator gmail.com> writes:
On Wednesday, 3 November 2021 at 22:21:53 UTC, Andrei 
Alexandrescu wrote:

 Prolly we could have both so people could use either "io" or 
 "std2".


What I would actually do is make it the year of the planned 
stable release.

For example we might not actually use "Stdv2" but instead 
"std2023". In years prior to that, it is now obviously a future 
version and thus subject to change, then when 2023 comes along, 
it is officially stablized and we can start playing with std 2024.

This pace of putting major breaking changes in a yearly schedule 
would also give people realistic expecations. No, it won't break 
next month, but yes, it might next year.
Nov 03 2021
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/3/21 8:46 PM, Adam Ruppe wrote:

 On Wednesday, 3 November 2021 at 22:21:53 UTC, Andrei Alexandrescu wrote:

 Prolly we could have both so people could use either "io" or "std2".


 
 What I would actually do is make it the year of the planned stable release.
 
 For example we might not actually use "Stdv2" but instead "std2023". In 
 years prior to that, it is now obviously a future version and thus 
 subject to change, then when 2023 comes along, it is officially 
 stablized and we can start playing with std 2024.
 
 This pace of putting major breaking changes in a yearly schedule would 
 also give people realistic expecations. No, it won't break next month, 
 but yes, it might next year.


Love this.
Nov 03 2021
prev sibling next sibling parent reply Max Samukha <maxsamukha gmail.com> writes:
On Thursday, 4 November 2021 at 00:46:35 UTC, Adam Ruppe wrote:


 For example we might not actually use "Stdv2" but instead 
 "std2023". In years prior to that, it is now obviously a future 
 version and thus subject to change, then when 2023 comes along, 
 it is officially stablized and we can start playing with std 
 2024.


What if it's behind schedule? You'd have to explain to people in 
2025 why the future version name is std2023. Also, std2023 is 
ugly.
Nov 03 2021
next sibling parent Adam D Ruppe <destructionator gmail.com> writes:
On Thursday, 4 November 2021 at 06:12:43 UTC, Max Samukha wrote:

 What if it's behind schedule?


Then you cut features and/or redouble their efforts to get back 
on schedule.

I assure you, the emperor is not as forgiving as I am.
Nov 04 2021
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/4/21 2:12 AM, Max Samukha wrote:

 On Thursday, 4 November 2021 at 00:46:35 UTC, Adam Ruppe wrote:
 

 For example we might not actually use "Stdv2" but instead "std2023". 
 In years prior to that, it is now obviously a future version and thus 
 subject to change, then when 2023 comes along, it is officially 
 stablized and we can start playing with std 2024.


 
 What if it's behind schedule? You'd have to explain to people in 2025 
 why the future version name is std2023. Also, std2023 is ugly.


Interestingly enough that's what happened to C++. The draft was C++0x 
for a long time until they realized they can't make it by 2010. The 
standard was ultimately C++11, and it was refreshed every three years 
right on schedule.

I can't understate just how successful their process is. We'd do good to 
learn from it.
Nov 04 2021
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Thursday, 4 November 2021 at 15:23:46 UTC, Andrei Alexandrescu 
wrote:

 Interestingly enough that's what happened to C++. The draft was 
 C++0x for a long time until they realized they can't make it by 
 2010. The standard was ultimately C++11, and it was refreshed 
 every three years right on schedule.

 I can't understate just how successful their process is. We'd 
 do good to learn from it.


What C++ is doing is nothing like what you propose.

C++ has only one standard namespace and that is "std", ("std??" 
is reserved).

C++ is by and large backwards compatible. Both language and 
standard lib. Only a tiny number of unused features have been 
deprecated and signatures have been modified in non-breaking ways 
for the most applications.
Nov 04 2021
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.com> writes:
On 2021-11-04 2:12, Max Samukha wrote:

 On Thursday, 4 November 2021 at 00:46:35 UTC, Adam Ruppe wrote:
 

 For example we might not actually use "Stdv2" but instead "std2023". 
 In years prior to that, it is now obviously a future version and thus 
 subject to change, then when 2023 comes along, it is officially 
 stablized and we can start playing with std 2024.


 
 What if it's behind schedule? You'd have to explain to people in 2025 
 why the future version name is std2023. Also, std2023 is ugly.


Right now it's std2xalpha, to be renamed to std22 or std23 etc when the 
version matures. I hope it won't spill into std3x :o).
Nov 08 2021
parent Max Samukha <maxsamukha gmail.com> writes:
On Monday, 8 November 2021 at 22:43:45 UTC, Andrei Alexandrescu 
wrote:


 Right now it's std2xalpha, to be renamed to std22 or std23 etc 
 when the version matures. I hope it won't spill into std3x :o).


Sorry for the delay. I don't quite understand why we have to copy 
that mistake of C++. How is encoding the excessive semantic 
information in a frequently used identifier better than just 
having std<N> plus a doc page with the release dates?
Nov 17 2021
prev sibling parent reply Andrey Zherikov <andrey.zherikov gmail.com> writes:
On Thursday, 4 November 2021 at 00:46:35 UTC, Adam Ruppe wrote:

 On Wednesday, 3 November 2021 at 22:21:53 UTC, Andrei 
 Alexandrescu wrote:

 Prolly we could have both so people could use either "io" or 
 "std2".


 What I would actually do is make it the year of the planned 
 stable release.

 For example we might not actually use "Stdv2" but instead 
 "std2023". In years prior to that, it is now obviously a future 
 version and thus subject to change, then when 2023 comes along, 
 it is officially stablized and we can start playing with std 
 2024.

 This pace of putting major breaking changes in a yearly 
 schedule would also give people realistic expecations. No, it 
 won't break next month, but yes, it might next year.


Why no to do the similar thing as C++ std does? The working name 
of the next version is std2x, then as soon as it's stabilized, 
it's renamed to std2023. The following version might be std2y -> 
std2027, for example. We can use "a", "b", "c" etc. to ensure 
that we don't run out of letters within the decade.
Nov 04 2021
next sibling parent Andrey Zherikov <andrey.zherikov gmail.com> writes:
On Thursday, 4 November 2021 at 13:23:57 UTC, Andrey Zherikov 
wrote:

Also why can't we change the major version of the compiler? Every 
major version will have different default version of phobos and 
support only few recent versions (to allow decommission of the 
old versions of phobos). Basically something similar to GCC.
Nov 04 2021
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/4/21 9:23 AM, Andrey Zherikov wrote:

 On Thursday, 4 November 2021 at 00:46:35 UTC, Adam Ruppe wrote:

 On Wednesday, 3 November 2021 at 22:21:53 UTC, Andrei Alexandrescu wrote:

 Prolly we could have both so people could use either "io" or "std2".


 What I would actually do is make it the year of the planned stable 
 release.

 For example we might not actually use "Stdv2" but instead "std2023". 
 In years prior to that, it is now obviously a future version and thus 
 subject to change, then when 2023 comes along, it is officially 
 stablized and we can start playing with std 2024.

 This pace of putting major breaking changes in a yearly schedule would 
 also give people realistic expecations. No, it won't break next month, 
 but yes, it might next year.


 
 Why no to do the similar thing as C++ std does? The working name of the 
 next version is std2x, then as soon as it's stabilized, it's renamed to 
 std2023. The following version might be std2y -> std2027, for example. 
 We can use "a", "b", "c" etc. to ensure that we don't run out of letters 
 within the decade.


Thanks, I'll do that. For now I'll use std2xalpha.
Nov 04 2021
prev sibling parent Salih Dincer <salihdb hotmail.com> writes:
On Wednesday, 3 November 2021 at 19:40:30 UTC, David Gileadi 
wrote:

 Bikeshed aside, named library versions may be more memorable 
 but they have the downside that it's much harder to see two 
 names and know which one is newer and/or current.




We wasting time! why not std2, just do it. Then we can change it 
with finger movement.
Nov 04 2021
prev sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 3 November 2021 at 19:40:30 UTC, David Gileadi 
wrote:

 Bikeshed aside, named library versions may be more memorable 
 but they have the downside that it's much harder to see two 
 names and know which one is newer and/or current.


Make Astronomy 101 a prerequisite for learning the language and 
pick stars ordered by distance from Earth.
Nov 03 2021
prev sibling parent reply Stanislav Blinov <stanislav.blinov gmail.com> writes:
On Wednesday, 3 November 2021 at 19:30:13 UTC, Andrei 
Alexandrescu wrote:

 On 2021-11-03 11:37, Andrei Alexandrescu wrote:

 I'd like to devise a robust version naming for Phobos. What is 
 the best way?
 
 Currently it's std.v2 but I'm unclear how it goes from there. 
 By semver we'd go with std.v2_0_1 and so on.
 
 Walter and others say it's better to have "std2" at top level 
 instead of "std.v2" nested inside std. I confess I chose 
 "std.v2" partially because it's easier to implement. But we 
 can go either way. What would be best?
 


 One thought; we could call version actual names, like Ubuntu 
 and OSX do. The version numbers will be a minor detail in the 
 documentation.


Please don't do that. Picking good names is hard, and such naming 
complicates communication between developers (esp. those not 
fluent in language of choice, or not familiar with name origins). 
What if a given name is just unnatural to pronounce in your 
language? And how do you even maintain the ordering then?

To me, it'd be "better" to have std at top level, not std2 or 
std1005000220. So how about turning it around? During 
development, whatever next iteration is would be stdNext (or 
std.next). At release, it becomes the new std and the *previous* 
one gets a number (i.e. in current circumstance it'll become 
std.v1). The number may even be date of retirement.
This way it can be made as alias internally, so we can keep 
whatever the actual number is rolling, and still be able to break 
things that need breaking, and get to have easier to implement 
"std.vN".

This makes what's actually standard always, well, standard.

If someone wants or needs old stuff for some reason, it becomes 
THEIR responsibility to maintain their compatibility (i.e. 
s/<std>/std.vX/g), as it should be.
Nov 03 2021
parent reply Andrey Zherikov <andrey.zherikov gmail.com> writes:
On Wednesday, 3 November 2021 at 20:03:48 UTC, Stanislav Blinov 
wrote:

 To me, it'd be "better" to have std at top level, not std2 or 
 std1005000220. So how about turning it around? During 
 development, whatever next iteration is would be stdNext (or 
 std.next). At release, it becomes the new std and the 
 *previous* one gets a number (i.e. in current circumstance 
 it'll become std.v1). The number may even be date of retirement.
 This way it can be made as alias internally, so we can keep 
 whatever the actual number is rolling, and still be able to 
 break things that need breaking, and get to have easier to 
 implement "std.vN".


I like the idea with std.next.

What's about publishing old versions of std to code.dlang.org?
Nov 03 2021
parent Stanislav Blinov <stanislav.blinov gmail.com> writes:
On Wednesday, 3 November 2021 at 21:04:14 UTC, Andrey Zherikov 
wrote:


 I like the idea with std.next.

 What's about publishing old versions of std to code.dlang.org?


Yup, old stuff needs to linger somewhere so people can migrate. 
For example, it gets published as std.vXYZ (with the appropriate 
folder structure). That's why using retirement date for XYZ can 
also be more informative than just an ordinal.
Nov 03 2021
prev sibling next sibling parent reply Guillaume Piolat <first.last gmail.com> writes:
On Wednesday, 3 November 2021 at 15:37:05 UTC, Andrei 
Alexandrescu wrote:

 I'd like to devise a robust version naming for Phobos. What is 
 the best way?

 Currently it's std.v2 but I'm unclear how it goes from there. 
 By semver we'd go with std.v2_0_1 and so on.

 Walter and others say it's better to have "std2" at top level 
 instead of "std.v2" nested inside std. I confess I chose 
 "std.v2" partially because it's easier to implement. But we can 
 go either way. What would be best?


My pick is stdnext.stuff
Nov 03 2021
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/3/21 8:25 PM, Guillaume Piolat wrote:

 On Wednesday, 3 November 2021 at 15:37:05 UTC, Andrei Alexandrescu wrote:

 I'd like to devise a robust version naming for Phobos. What is the 
 best way?

 Currently it's std.v2 but I'm unclear how it goes from there. By 
 semver we'd go with std.v2_0_1 and so on.

 Walter and others say it's better to have "std2" at top level instead 
 of "std.v2" nested inside std. I confess I chose "std.v2" partially 
 because it's easier to implement. But we can go either way. What would 
 be best?


 
 My pick is stdnext.stuff


And then? stdnextnext?
Nov 03 2021
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Thursday, 4 November 2021 at 04:07:56 UTC, Andrei Alexandrescu 
wrote:

 On 11/3/21 8:25 PM, Guillaume Piolat wrote:

 My pick is stdnext.stuff


 And then? stdnextnext?


No, instead of being backwards compatible you aim for being 
forward compatible.

So you prepare for the next major language release by giving 
early access through a "next" namespace. When you hit the major 
language release you rename it to "std" and phase out the 
outdated "std".
Nov 04 2021
prev sibling next sibling parent reply zjh <fqbqrr 163.com> writes:
On Wednesday, 3 November 2021 at 15:37:05 UTC, Andrei 
Alexandrescu wrote:

 I'd like to devise a robust version naming for Phobos. What is 
 the best way?


`std->std0->std`.
`std->std0->std`.
Always Only One Std Version.

`std0` is just Intermediate state name.
`std0` internal add a `year` as `private alias version name` such 
as `std2021`.
Nov 03 2021
next sibling parent zjh <fqbqrr 163.com> writes:
On Thursday, 4 November 2021 at 00:38:24 UTC, zjh wrote:


 `std->std0->std`.


`std0` is similar to the `C++latest` switch, and `std` is the 
stable version.
We didn't do anything, we got the `stable/latest` version. 
`Win-win`.
You need `stable version`,Ok use `std`. You need `latest 
version`,ok use `std0`.
It also takes `3` months to enter the stable version. At the same 
time, it is synchronized with the release of `DMD`.
Why? Because many people want to use the latest features at the 
first time.
Users of the stable version also hope to get the latest version 
without modification.
Large and full use, but also easier to expose `bugs`.
Nov 03 2021
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/3/21 8:38 PM, zjh wrote:

 On Wednesday, 3 November 2021 at 15:37:05 UTC, Andrei Alexandrescu wrote:

 I'd like to devise a robust version naming for Phobos. What is the 
 best way?


 
 `std->std0->std`.
 `std->std0->std`.
 Always Only One Std Version.
 
 `std0` is just Intermediate state name.
 `std0` internal add a `year` as `private alias version name` such as 
 `std2021`.


No because this will break all existing code.
Nov 03 2021
parent reply zjh <fqbqrr 163.com> writes:
On Thursday, 4 November 2021 at 04:07:39 UTC, Andrei Alexandrescu 
wrote:

 On 11/3/21 8:38 PM, zjh wrote:


Just an private `alias`,where is break?

`version std0=std2021`,is so easy.

`std.v2_0_1`,too ugly.This is not the right way.

User only need change `std` to `std0`,and every new feature is Ok 
for use.If he want `stable` release,He does nothing.`std` is 
already there .
`Just` maintainer merge `std0` into `std`.
Nov 03 2021
parent reply zjh <fqbqrr 163.com> writes:
On Thursday, 4 November 2021 at 05:45:14 UTC, zjh wrote:


 `Just` maintainer merge `std0` into `std`.


`Just` like `git` merge into `std` stable release.`std=std0(3 
month later mergin into`.
We always two `branch`:`std(stable)`+`std0(latest,unstable)`.
Nov 03 2021
parent reply zjh <fqbqrr 163.com> writes:
On Thursday, 4 November 2021 at 05:59:43 UTC, zjh wrote:


I use C++ and always add `C++ latest` switch, which is very 
convenient.
Nov 03 2021
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Thursday, 4 November 2021 at 06:06:33 UTC, zjh wrote:

 I use C++ and always add `C++ latest` switch, which is very 
 convenient.


What I find annoying with C++ (Clang and Xcode) is that the next 
language features are implemented and ready before the standard 
library. It can take like a year or so before we get the standard 
library up to date in C++. (Microsoft currently do better, I 
think).
Nov 04 2021
parent zjh <fqbqrr 163.com> writes:
On Thursday, 4 November 2021 at 08:49:52 UTC, Ola Fosheim Grøstad 
wrote:
C++. (Microsoft currently do

 better, I think).


`C++`'s `concepts and ... ` are very convenient to use. When 
implementing functions, it is very concise.
Nov 04 2021
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/3/2021 8:37 AM, Andrei Alexandrescu wrote:

 By semver we'd go with std.v2_0_1 and so on.


I understand its technical merits, but having to look at v2_0_1 is unbearably
ugly.
Nov 03 2021
parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Thursday, 4 November 2021 at 02:59:47 UTC, Walter Bright wrote:

 On 11/3/2021 8:37 AM, Andrei Alexandrescu wrote:

 By semver we'd go with std.v2_0_1 and so on.


 I understand its technical merits, but having to look at v2_0_1 
 is unbearably ugly.


Agreed, I wouldn't be able to sleep at night if it looked like 
that
Nov 04 2021
prev sibling parent dd <dd dax.moe> writes:
On Wednesday, 3 November 2021 at 15:37:05 UTC, Andrei 
Alexandrescu wrote:

 Currently it's std.v2 but I'm unclear how it goes from there. 
 By semver we'd go with std.v2_0_1 and so on.


I'm fine with std.v2 or next.std or next.std.v2 or future.std or 
similar. They all show a clear name that these will be the next 
version. std2023 and std.v2_0_2 and the lot looks ugly and seem 
unpractical in a sense where you will have to maintain a 
multitude of minor versions.

It would be easier to have std.v2 and std.v3 because then it's 
simply a question of remapping the functions to major versions. 
It's already a little painful trying to map out which compilers 
version support what.
Nov 04 2021