FPC 3.2.2 is feature complete and pretty much ok for the vast majority of users.
Perhaps, but there are still easily fixable bugs. Unfortunately, even with the proposed fixes, some "core devs" remain very resistant to any change.
Resistant against change with trumped up benefits, yes. And an all or nothing attitude. No starting small or doing experments, just our way or the highway for changes that affect the whole organisation of the new fixes branch. Everything. Do you think that is a positive mindset ?
In the past big changes were always phased in by starting small and then expanding over time as experience with features grew.
Since the gitlab migration (which was rammed through within 6 weeks, and nothing concrete was done for releasing), Michael suddenly wants to force everything without experimentation of phasing. Just some grand ideas, with argumentation that has enormous gaps, and as only choice giving him free reign or being essentially painted as the dinosaur that holds up all change. And that is why you are gullible Fred, because you believe that.
But keep in mind that while I often say no, I'm at least here taking the time to answer your questions in detail.
We already have snapshots.
Of FPC 3.2.4 with regular fixes?
FPC 3.2.4 is not a live branch, but yes, of fixes (3.2.3), from which 3.2.4 was branched. E.g.
https://downloads.freepascal.org/fpc/snapshot/v32/i386-win32/I think 3.2.3 is nearly equal to 3.2.4RC1, with maybe a few post RC1 fixes, despite having a lower number (3.2.3<3.2.4)
Note that with snapshot I meant blessing a simple build as release without a proper process or investigation (are all things that can be merged really merged? Are there still showstopper changes?). Just because of the timer, do a build and bless it as release. The format might be different than a snapshot, but the checks on content are the same.
And it is in those processes where the hangup is, not in the bulk merging as Michael argues on those threads.
If so, then there are no more valid excuses for not releasing a new version every 6 months.
See my last posts on that thread. _I_ always did nearly all the merging, also in the GIT era. Michael merges only a fraction of his own changes (e.g. fcl-passrc and fcl-web where he does most work are hardly changed since 3.2.2). VCL-COMPAT is merged to a higher degree to fixes, but that was mostly done by yours truly, not Michael.
The timer only signals that the current state is pushed out (and with only automated quality control, most of which stilll must be crafted, and probably never will for 3.2.4). It doesn't provide anything to make sure there is actually something in there. And such proposal from sb who never merged the bulk of his own changes to fixes is therefore doubtful.
Logically, we should have a > 3.2.10 release by now.
If this had been implemented in gitlab change times (when this was proposed), we might even be further. But it would essentially contain the same as 3.2.2, as the timer does nothing about actually providing content.
I don't mind going to a timebased schedule, but I want to see proposals to also tackle the release content side of things (and not try to create rosy coloured smoke screens by saying that automated systems from gitlab or AI will do everything).
So back during the pre gitlab migration discussions, it was agreed that timebased schedule was a thing worth trying, but that we first would try to automate and accelerate the fixes release to find out what frequency was workable, and make sure that content wouldn't suffer. Joost and Michael would start working on that, and no progress report was ever received. To my knowledge they dabbled a bit in automating crosscompilation of the snapshots, but it was never finalised or evaluated.
So the fact is that due to there never have been a release in the gitlab era, the effective automation of releases now is less than it was during 3.2.2 times. But Michael keeps blaming all release delays on automation, while not perfect, it wasn't any immediate cause.
Asking all people what problems were remaining with a branch (e.g. processing RC1 feedback, and newer bugreports), and then actually fixing the remaining outstanding bugs was the problem, specially for the major releases.
The actual building of the binaries mostly took the maintainers half an hour, and a bit more for the RCs. I've build the windows RC1 binaries in hour (but that was mostly due to changes made to the innosetup), and the freebsd the day after in 2hrs. Linux is a bit more complicated due to often emerging small problems in trying to remain the TGZ compatible with multiple distributions.
I assume that OS X/iOS is also a bit more involved due to annual changes (both OS, as the XCode/binutils tooling it depends on, as well as new security features.
Yes, maybe a script could do it all with a single button press, but building was always in weekends, and finding 2hrs to do it is not the reason for 5 year release hiatus.
Read thread and my replies carefully, and check the things I say, and you'll see a pattern emerge.
Recent
