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 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
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 parent Walter Bright <newshound2 digitalmars.com> writes:
Your ideas sound pretty sensible to me.
Jul 25