Op 15-4-2026 om 20:09 schreef Marco van de Voort via fpc-devel:
It is the exact opposite of my central idea. Which is "More release
workers, less release workflow designers". Specially not workflow
designers that never took any responsibility for the release project
before.
Some bits that I considered after the last mail:
A) For the people that want to play the release automation card:
1) Realise that release automation is _NOT_ the bottleneck in the
release process. Actually making sure the branch would produce a
workable release is the bottleneck. This is usually either ignored (but
any automation will /surely/ help?) or suggesting to skip that step
outright. But skipping this step is not really about releasing any more,
but basically rebranding snapshots as releases. And that is a token
change only, since snapshots are already provided, and obviously don't
satisfy the need for a release (or we would not be having this discussion)
2) If you _still_ want to do automation, please start with the Tier 1
platforms in this order: (1) Mac OS X (2) Windows (3) Linux. As most
Linux detail release work happens in the distribution packaging, putting
it first is too low a bar. OS X in recent history has been the most
problematic of the Tier 1 targets, so anything that you can do to keep
the current live branches up to date with the current (annual) iteration
of OS X would be hugely beneficial. That is no disrespect to Jonas btw,
it is simply the reality of a annual release that nearly always breaks
something. And those breakages are often non trivial. Windows has had
its problems too (let's not forget the SEH32 rework that held up the
3.2.0 release), but those are increasingly more isolated due to having
internal binutils and a very stable ABI/API.
If you want to "fix" releasing and you own an up to date Mac, that is
surely where the efforts should have the best ROI. Much more than
writing a few makepack alike scripts.
3) Similar claims (CI, automated releases) were made during the 2021
gitlab migration by Michael and Joost. It would be good to find out what
became of those efforts. At least I never heard of them again.
B) Another fundamental flaw of plans like yours is that the assumption
that the relation between main/trunk and release branches (of any
policy) is simply a matter of selecting a few winner revisions to merge,
and ignore the rest.
After 1-2 years however most compiler revisions are however attached to
major reworks or restructures of the compiler.
Your process doesn't provide any tools to solve that problem, it merely
reiterates an over idealistic view of cherry picking random unrelated
versions to release branches. A prime example is the said loadppu
rework of may 2024 that made the main branch unstable after more than 5
full years of development (the 3.2.x branch was branched from the main
branch in summer 2018 iirc), making a speedy major branch release hopeless.
_______________________________________________
fpc-devel maillist - [email protected]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
