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.

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".

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.

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.

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.

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.