Op 7-4-2026 om 13:13 schreef Michael Van Canneyt via fpc-devel:
It is an organised endeavour, not a mindless robo-act.
We're talking about building a release at regular intervals.
The fixes branch as is yes. And I said that the problem is making sure
things to be released *are* in the fixes branch.
If we limit what goes in, testing will be reduced to minimum, making it
perfectly doable.
Current minor releases are also doable. It just needs to be done. With
the same attitude as now, that leads to empty releases just because the
timer ticks. The work overhead per actually delivered fix to the user
only increases.
If of course we mindlessly merge in whatever pops into our head, we're in
for a bad ride.
That a major release is more complicated does not diminish the value of
regular releases for the user in any way.
This was basically the situation before I started working on releases in
2.0.4 times, and it doesn't work.
Making fixes releases with a handful of emergency fixes, only wides the
gap between fixes and the next major release even more, which results in
unusable .0 releases and you still don't resolve most the frustration
with the current scheme.
Namely that users have to wait a long time (till the next major release)
before they see a fix back in a release.
Just saying that you have recently essentially rebuilt the last release
with a few fixes won't make that go away.
The problem is the human factor, not policies or build technology, but
actually executing the policies and using the tools that are there. Time
based or old style doesn't matter.
If you manage to accelerate that (and more often releases leads to more
polishing of the details of the process), you might actually change
something with the release schedule. Pinning all your hope on near empty
robo builds to circumvent the human factor won't.
_______________________________________________
fpc-devel maillist - [email protected]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
