am i right in saying that "134 open merge requests" means that if those 134 requests were applied to the last official FPC release (3.2.2) this would bring it fully up to date with the most recent sources on GitLab?
if this is so, and on the basis that 3.2.2 has been working reasonably well for almost everyone who uses FPC to generate binary applications (as opposed to those who merely enjoy tinkering with the internals of a compiler), might i suggest the following strategy: pick a handful of merges that (a) provide USEFUL improvements, and (b) are non-contentious. eg, stop the CPU catching fire on long compiles, perhaps add a feature that everyone desperately desires. by a handful, i mean 5 or 6. and the list need not be 'perfect', this is not something as important as creating the perfect mix tape to catch the heart of the love of your life! now apply the above list (of 5 or 6 merges), and generate a release candidate - a COMPLETE release, like the releases on SourceForge. none of this 'clone the repository and compile it yourself' faff. put it out there, on SourceForge, and sit back and wait. if there are no complaints in the next 4 weeks, repeat with another handful of merges. it seems to me that given the past lack of progress in the last 4+ years, this is the ONLY way to move forward. cheers, rob :-) _______________________________________________ fpc-devel maillist - [email protected] https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
