www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - On dmd 2.112, future releases, and LTS

reply Dennis <dkorpel gmail.com> writes:
This year I took over the release process from Iain, not because 
I am so qualified as a 'DevOps Engineer' (I actually had to look 
that term up) but out of necessity. Therefore I planned to just 
'cruise' for the time being and follow the existing process 
without touching anything. However, the current release process 
causes so much friction that I want to change it sooner rather 
than later. For the Symmetry Autumn of Code (SAoC), there is an 
idea for a project to streamline the release process. This is 
mostly about the infrastructure for building releases and 
uploading the downloads to the server. What I want to discuss now 
is the release schedule, branching strategy, and contributor 
experience.


- The distinction between the master/stable branch is vague and 
time-dependent. Some say stable is for 'critical' bug fixes, 
other say it's for 'safe' bug fixes, but DMD's semantic analysis 
order is so fragile that even 'safe' bug fixes have caused 
projects to break after an update from release candidate to 
actual release version.
- Pull Requests that target the default master branch often 
contain discussions "please rebase to stable", "won't do because 
X", "will do because Y", "okay I tried but now commits are all 
messed up", etc. This wastes the contributor's and reviewer's 
time.
- Stable constantly needs to be manually merged into master to 
prevent conflicts and keep nightly up to date
- Patch releases are not possible after master gets merged into 
stable. So once I build a beta for 2.112.0, I can't build 2.111.1 
anymore.
- Relatedly, people have requested LTS (Long Term Stable) 
releases which don't fit into our current branch structure
- The frequency of beta, release candidate, and patch versions is 
high, adding to the workload of the release manager while there 
are still so many manual steps in the process. Following the 
existing cadence I'd build 4 releases in a span of 4 weeks. Many 
of these releases only differ by a handful of commits, and while 
there is no urgent problem with server storage, the gigabytes are 
slowly piling up.
- To add to that, only a small percentage of people actually seem 
to actually test beta/rc versions. Most regression bug reports 
come in after a release has been pushed to package managers.
- Releases are tagged purely based on time, even when we're in 
the middle of a series of incremental pull requests, causing 
half-finished work to unintentionally appear in a release 
sometimes.


- All contributions go into the master branch.
- Every 3 months a feature freeze for a minor version is created 
in a branch called 2.XXX
- Maintainers can add a 'backport-to-2.XXX' label to a PR, 
triggering a GitHub Action to merge it into that version branch 
(unless there are merge conflicts, then manual action is required)
- 'stable' points to the latest minor release branch for 
backwards compatibility
- Nightly builds continue as always, being built from master
- Consider making 1/4 releases (or 1 per year) Long Term Stable 
(LTS)
- Backports to LTS / feature branches are done on an as-needed 
basis. Patch releases aren't created based on whatever bugs 
happened to be fixed the month after the first minor release, but 
because critical bugs/regressions popped up that prevented 
(industry) users from getting work done.
- Try using GitHub milestones to coordinate features with release 
versions

Maintainers still need to decide what master commits go into what 
version branch, and merge conflicts can still happen, but at 
least this should remove most accidental complexity. We no longer 
need to pester authors of Pull Requests about which branch to 
target, and there's much more clarity on what's happening: You 
don't need to cross-reference the release schedule with the PR's 
merge timing to figure out where it's ending up.



If I missed any (technical) considerations, please let me know. 
This is just my proposal based on current observations, it can be 
adjusted as we go. For example, the frequency of releases can be 
increased if there's demand and the process gets streamlined.



I won't implement this before DConf, I'm currently focussing on 
building 2.112.0. I need to update the Visual Studio installation 
on the Windows VM to make that work. I'm also looking to add a 
certificate to the MacOS releases (courtesy of  LunaTheFoxgirl, 
thanks!), which also requires changing what happens inside the 
MacOS VM. Like I said, this is all new to me, so if anyone wants 
to help out that would be appreciated.
Jul 15
next sibling parent reply monkyyy <crazymonkyyy gmail.com> writes:
On Tuesday, 15 July 2025 at 11:46:46 UTC, Dennis wrote:

 - Relatedly, people have requested LTS (Long Term Stable)



 - To add to that, only a small percentage of people actually 
 seem to actually test beta/rc versions.


There hasnt been much difference; did upstream ever even fix that 
template regression I found from a incorrect optimization?

There have to be some sort of trade off to make a choice worth 
considering but development speed is slow here, tech debt high, 
bug reports closed erroneously or playing wakeamole with a 
minimized case without actually addressing real uses.

If Im syntax testing ussally code goes back to 100 or 90; its 
shocking how much of my weird template code on "all compilers" 
fails because of my habit of "import std;"

---

Theres 2 reasons to be on the bleeding edge: a favor for the 
community with my bug reports being taken srsly or features that 
arrive on time to be used. Neither on on offer so why pretend?

Evidence of wasted effort(no one using the beta) is a strange 
reason to suggest adopting even more possible wasted effort 
(maintaining an lts)
Jul 15
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/15/2025 10:05 AM, monkyyy wrote:

 its shocking how much 
 of my weird template code on "all compilers" fails because of my habit of 
 "import std;"


"import std;" is probably something to be avoided:

1. it's going to make your compile s l o o o w

2. if something goes wrong, you've got a giant morass of code to slog through, 
99% of which will be irrelevant to your program
Jul 25
parent reply monkyyy <crazymonkyyy gmail.com> writes:
On Saturday, 26 July 2025 at 00:53:45 UTC, Walter Bright wrote:

 On 7/15/2025 10:05 AM, monkyyy wrote:

 its shocking how much of my weird template code on "all 
 compilers" fails because of my habit of "import std;"


 "import std;" is probably something to be avoided:

 1. it's going to make your compile s l o o o w


1. no, import std is less impactful on compile times then the dub 
overhead that the majority of the community thoughtlessly pushes. 
My code compiles effectively instantly and always has.


 2. if something goes wrong, you've got a giant morass of code 
 to slog through, 99% of which will be irrelevant to your program


I treat this language as black boxes; I dont trust the spec, I 
dont read the page long rants called docs, when something breaks 
I write 10 lines of code and not untangle your 1000 line 
implementation.

It makes no difference how I import phoboes, as everything in 
phoboes imports everything else. its all a mess, its all complex, 
its all hard to read, 10000 lines or 100000 lines doesn't matter 
Im not functioning on a level where I can do anything but declare 
bankruptcy when it breaks.

Your 30 or 40 years of experience with one code base may say 
otherwise, but you have so much tech debt here. Theres no 
catching up to your expertise; its a brick wall.

I push for heavy syntax testing, which is to say minimizing buggy 
code preemptively, assuming the bugs are there because so often 
they are; its better to write 10 lines of code around an 
untrusted black box to see it it can be trusted then write 1000 
lines and *when* the bug hits you iterate down to the 10+ some 
piece of phoboes/template bugs that break.
Jul 25
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/25/2025 8:41 PM, monkyyy wrote:

 It makes no difference how I import phoboes, as everything in phoboes imports 
 everything else. its all a mess, its all complex, its all hard to read


You are correct. This is why Adam Wilson is working on Phobos2.
Jul 26
parent reply kdevel <kdevel vogtner.de> writes:
On Saturday, 26 July 2025 at 17:43:56 UTC, Walter Bright wrote:


 [...] This is why Adam Wilson is working on Phobos2.


Sorry for hijacking this thread. Is there any feature list/preview
available besides [1]?

I would like to suggest the following improvements:

- Remove "hnsecs" [2]. Every time I read this I am under the
   impression that somebody is mocking the SI prefix system [3].
   My suggestions [4] and [5] are of 2019.

- Rename the function "deleteme". I cannot easily parse this.
   Shall I delete the occurrence of "deleteme" in the source code?
   Shall I delete a file named after the return value of the 
deleteme
   function? Has this file already been created? More questions 
than
   answers. The meaning of the tmpnam function [6] is as oppposed 
to
   deleteme glass-clear.

- Remove the function "browse" from std.process [7].

[1] https://wiki.dlang.org/Language_issues#std2
[2] https://dlang.org/library/core/time/hnsecs.html
[3] https://en.wikipedia.org/wiki/Metric_prefix
[4] 
https://forum.dlang.org/post/khppfxsyfefjksvrimkx forum.dlang.org
[5] 
https://forum.dlang.org/post/ghkpbbuatvjemthqrkxb forum.dlang.org
[6] https://man7.org/linux/man-pages/man3/tmpnam.3.html
[7] https://dlang.org/phobos/std_process.html#.browse
Jul 31
next sibling parent reply 0xEAB <desisma heidel.beer> writes:
On Thursday, 31 July 2025 at 21:34:03 UTC, kdevel wrote:

 - Remove "hnsecs" [2]. Every time I read this I am under the
   impression that somebody is mocking the SI prefix system [3].


It’s Win32’s unit of time.
Jul 31
parent reply kdevel <kdevel vogtner.de> writes:
On Thursday, 31 July 2025 at 23:57:49 UTC, 0xEAB wrote:

 On Thursday, 31 July 2025 at 21:34:03 UTC, kdevel wrote:

 - Remove "hnsecs" [2]. Every time I read this I am under the
   impression that somebody is mocking the SI prefix system [3].


 It’s Win32’s unit of time.


Do you have any reference to MS documentation which defines 
"hnsecs"?

The granularity of time seems to be 100 ns which seems to be named
a "tick" [1]. I mean nobody would invent the "unit" "tKiBytes"
(tetra kibi-byte) when everybody calls it "pagesize" (on X86).

[1] 
https://learn.microsoft.com/en-us/dotnet/api/system.timespan.ticks?view=net-9.0#System_TimeSpan_Ticks
Aug 01
next sibling parent reply Quirin Schroll <qs.il.paperinik gmail.com> writes:
On Friday, 1 August 2025 at 10:12:12 UTC, kdevel wrote:

 On Thursday, 31 July 2025 at 23:57:49 UTC, 0xEAB wrote:

 On Thursday, 31 July 2025 at 21:34:03 UTC, kdevel wrote:

 - Remove "hnsecs" [2]. Every time I read this I am under the
   impression that somebody is mocking the SI prefix system 
 [3].


 It’s Win32’s unit of time.


 Do you have any reference to MS documentation which defines 
 "hnsecs"?

 The granularity of time seems to be 100 ns which seems to be 
 named
 a "tick" [1]. I mean nobody would invent the "unit" "tKiBytes"
 (tetra kibi-byte) when everybody calls it "pagesize" (on X86).

 [1] 
 https://learn.microsoft.com/en-us/dotnet/api/system.timespan.ticks?view=net-9.0#System_TimeSpan_Ticks


Well, “tetra” isn’t even an SI prefix, whereas hectonanosecond 
combines two SI prefixes, which isn’t allowed if you want to 
comply to SI rules, which we’re not bound to. In my personal 
opinion, hns is very much understandable.

Also, “tick” and “pagesize” in my brain sound like concepts 
relative to a platform (like `size_t`), whereas “tetrakibibyte” 
is an absolute measure of information and “hectonanosecond” is an 
absolute measure of time. A tick is in fact so murky that the 
C++20 STL [requires clock 
types](https://en.cppreference.com/w/cpp/chrono/is_clock.html) to 
have an `is_steady` member that returns `true` only if ticks have 
the same length.

I don’t know if D supports any platform in which ticks aren’t 
steady or are different from 100 ns. DMD probably not, but with 
GDC and LDC, I wouldn’t say no without investigating.

The C++ STL simply defines nanoseconds, and if you use a 
nanoseconds value that’s not a multiple of 100, that information 
might go unused. With 64 bits, you can only have so many values, 
and that is actually a problem: The amount of nanoseconds between 
the years 1 and 2026 is: 1E9 × 60 × 60 × 24 × 365.2425 × 2025, 
which is a number that requires 66 bits to store. With 64 bits, 
you only get from year 1 to around year 584. If you store an hns 
value, you can model 58,455 years, which is more than enough. 
Even if you take away one bit for sign and half the range for 
years before year 1, you still have 14,613 for each direction.
Aug 01
parent kdevel <kdevel vogtner.de> writes:
On Friday, 1 August 2025 at 17:26:30 UTC, Quirin Schroll wrote:

 [...] With 64 bits, you can only have so many values, and that 
 is actually a problem: The amount of nanoseconds between the 
 years 1 and 2026 is: 1E9 × 60 × 60 × 24 × 365.2425 × 2025, 
 which is a number that requires 66 bits to store. With 64 bits, 
 you only get from year 1 to around year 584.


128 bits solve this problem:

            struct timespec {
                time_t tv_sec;        /* seconds */
                long   tv_nsec;       /* nanoseconds */
            };
Aug 02
prev sibling parent reply 0xEAB <desisma heidel.beer> writes:
On Friday, 1 August 2025 at 10:12:12 UTC, kdevel wrote:

 On Thursday, 31 July 2025 at 23:57:49 UTC, 0xEAB wrote:

 On Thursday, 31 July 2025 at 21:34:03 UTC, kdevel wrote:

 - Remove "hnsecs" [2]. Every time I read this I am under the
   impression that somebody is mocking the SI prefix system 
 [3].


 It’s Win32’s unit of time.


 Do you have any reference to MS documentation which defines 
 "hnsecs"?


Sure, check out `FILETIME`:
<https://learn.microsoft.com/en-us/windows/win32/api/minwinbase/ns-minwinbase-filetime>
Aug 01
parent reply kdevel <kdevel vogtner.de> writes:
On Friday, 1 August 2025 at 21:18:24 UTC, 0xEAB wrote:

 [...]
 It’s Win32’s unit of time.


 Do you have any reference to MS documentation which defines 
 "hnsecs"?


 Sure, check out `FILETIME`:
 <https://learn.microsoft.com/en-us/windows/win32/api/minwinbase/ns-minwinbase-filetime>


My browser cannot find any of the strings "hns" and "hecto" on 
that page.
(That tics are 100 ns long is not disputed).
Aug 02
next sibling parent "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 03/08/2025 9:51 AM, kdevel wrote:

 On Friday, 1 August 2025 at 21:18:24 UTC, 0xEAB wrote:

 [...]
 It’s Win32’s unit of time.


 Do you have any reference to MS documentation which defines "hnsecs"?


 Sure, check out `FILETIME`:
 <https://learn.microsoft.com/en-us/windows/win32/api/minwinbase/ns- 
 minwinbase-filetime>


 
 My browser cannot find any of the strings "hns" and "hecto" on that page.
 (That tics are 100 ns long is not disputed).


You won't find the name for the unit there.

Hecto nano second is an entirely us creation for the name.

The unit in terms of being 100 ns is not an us creation, which is what 
that page shows.

I am not defending this decision, for my datetime library I went with 
nano seconds.
Aug 02
prev sibling parent reply 0xEAB <desisma heidel.beer> writes:
On Saturday, 2 August 2025 at 21:51:24 UTC, kdevel wrote:

 On Friday, 1 August 2025 at 21:18:24 UTC, 0xEAB wrote:

 [...]
 It’s Win32’s unit of time.


 Do you have any reference to MS documentation which defines 
 "hnsecs"?


 Sure, check out `FILETIME`:
 <https://learn.microsoft.com/en-us/windows/win32/api/minwinbase/ns-minwinbase-filetime>


 My browser cannot find any of the strings "hns" and "hecto" on 
 that page.
 (That tics are 100 ns long is not disputed).


Looking at the quote “the number of 100-nanosecond intervals” — 
what else would the prefix “100-” mean if not “hecto”?
Aug 03
parent kdevel <kdevel vogtner.de> writes:
On Sunday, 3 August 2025 at 22:51:48 UTC, 0xEAB wrote:

 On Saturday, 2 August 2025 at 21:51:24 UTC, kdevel wrote:

 On Friday, 1 August 2025 at 21:18:24 UTC, 0xEAB wrote:

 [...]
 It’s Win32’s unit of time.


 Do you have any reference to MS documentation which defines 
 "hnsecs"?


 Sure, check out `FILETIME`:
 <https://learn.microsoft.com/en-us/windows/win32/api/minwinbase/ns-minwinbase-filetime>


 My browser cannot find any of the strings "hns" and "hecto" on 
 that page.
 (That tics are 100 ns long is not disputed).


 Looking at the quote “the number of 100-nanosecond intervals” — 
 what else would the prefix “100-” mean if not “hecto”?


So there is no reference to /MS/ documentation which /literally/
defines those abbreviations "hns", "hnsecs" etc.
Aug 04
prev sibling next sibling parent 0xEAB <desisma heidel.beer> writes:
On Thursday, 31 July 2025 at 21:34:03 UTC, kdevel wrote:

 Sorry for hijacking this thread. Is there any feature 
 list/preview
 available besides [1]?


- <https://github.com/dlang/phobos/tree/master/phobos>
- <https://github.com/dlang/PhobosV3-Design>
Jul 31
prev sibling parent Steven Schveighoffer <schveiguy gmail.com> writes:
On Thursday, 31 July 2025 at 21:34:03 UTC, kdevel wrote:

 I would like to suggest the following improvements:

 - Remove "hnsecs" [2]. Every time I read this I am under the
   impression that somebody is mocking the SI prefix system [3].
   My suggestions [4] and [5] are of 2019.


"remove" from outputs, I would agree. In that linked thread, I 
think I agreed with you on that (just print 100 ns instead of 1 
hnsecs), or even better, just print the decimal (which is 
actually trivial, you don't even need it as a float). I might 
work on this.

In terms of hnsecs, I don't think we can remove it. But we can 
redefine it to mean "hundred nanoseconds".

-Steve
Aug 04
prev sibling next sibling parent reply 0xEAB <desisma heidel.beer> writes:
On Tuesday, 15 July 2025 at 11:46:46 UTC, Dennis wrote:

 What I want to discuss now is the release schedule, branching 
 strategy, and contributor experience.


Thanks for the update — much appreciated!

By the way, I feel like this could have been posted as an 
announcement instead. I can only speak for myself but I would 
have almost missed this post here in the “General” newsgroup and 
only stumbled over it by accident.
Jul 23
parent 0xEAB <desisma heidel.beer> writes:
On Wednesday, 23 July 2025 at 19:45:55 UTC, 0xEAB wrote:

 By the way, I feel like this could have been posted as an 
 announcement instead.


Forgot to add this: To me the post read more like an announcement 
than a RFC.
Jul 23
prev sibling next sibling parent Bastiaan Veelo <Bastiaan Veelo.net> writes:
On Tuesday, 15 July 2025 at 11:46:46 UTC, Dennis wrote:

 I need to update the Visual Studio installation on the Windows 
 VM to make that work.


Just a heads up: I did an upgrade to Visual Studio Community 2022 
17.14.9 today, and it broke my debug builds. The linker kept 
running out of stack space. Had to roll back to a previous 
version, in my case Visual Studio Community 2022 17.4.4.

https://developercommunity.visualstudio.com/t/Linker-fails-with-STATUS_STACK_BUFFER_OV/10942393?

-- Bastiaan.
Jul 24
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
Your ideas sound pretty sensible to me.
Jul 25
prev sibling parent Atila Neves <atila.neves gmail.com> writes:
On Tuesday, 15 July 2025 at 11:46:46 UTC, Dennis wrote:

 This year I took over the release process from Iain, not 
 because I am so qualified as a 'DevOps Engineer' (I actually 
 had to look that term up) but out of necessity. Therefore I 
 planned to just 'cruise' for the time being and follow the 
 existing process without touching anything. However, the 
 current release process causes so much friction that I want to 
 change it sooner rather than later. For the Symmetry Autumn of 
 Code (SAoC), there is an idea for a project to streamline the 
 release process. This is mostly about the infrastructure for 
 building releases and uploading the downloads to the server. 
 What I want to discuss now is the release schedule, branching 
 strategy, and contributor experience.

 [...]


Makes sense to me.
Jul 31