I would like to propose to separate RTL release   from compiler release so that RTL bug fixes and features can be released with shorter release cycle. Is that possible?

Zamrony P. Juharahttps://github.com/zamronypj

No, the RTL and the compiler are tightly coupled.

What might be possible are further packages like the FCL and interfaceing units, but the core RTL itself definitely not.

Regards,
Sven

Hi,

I think the need comes from the fact that the release cycle for the compiler is horribly long, which I tend to agree with. But I think this comes from the fact that the release for Tier 1 platforms is still mostly prepared manually. So if we want to improve on that, we need to improve the automated packaging of relase-ready binaries at least for Windows, Linux and MacOS, so Tier 1 systems. Linux is a no brainer, but I've no clue about what would automating the packaging the Windows or macOS installers involve.

Fix me?

Charlie

Windows is also a no-brainer, it's perfectly scriptable. We're using inno setup.

But MacOS is a problem.

Michael.

Michael Van Canneyt wrote

But MacOS is a problem.

macOS is also perfectly scriptable, I just have to finish automating it. The main remaining problem is our hard-wrapped readme and whatsnew files that look terrible in its installer (because it also performs wrapping and it uses a proportional font, so many hard-wrapped lines get wrapped again). So at least the changed/new parts need manual unwrapping every time.

For Mac OS X/PowerPC there is the additional issue that the tool to create installer packages that work on Mac OS X 10.4 no longer works under macOS 10.14, so they have to be created on an older Mac OS X version (I don't know when it broke exactly).

Jonas

I didn't mean to imply that it is not scriptable.

But it's a problem for the reasons you mention below. At least the first reason was known to me and one of the reasons why I described mac as problematic.

Manual work and requiring an old OS are a problem if you want to automate.

From what you say, both problems are related to the tool you use.

Are there no other tools that can be used ?

I don't know whether Mac OS X/PowerPC still qualifies as a Tier-1 platform;
But I doubt it. So maybe that can be dropped for these "intermediate" releases.

Michael.

Hi,

Well, if we're talking about automation, I'm sure some VM can be set up, and then it almost doesn't matter which version of macOS it is, until it works.

I don't know whether Mac OS X/PowerPC still qualifies as a Tier-1 platform; But I doubt it. So maybe that can be dropped for these "intermediate" releases.

Indeed, but if there's a script which anyone can execute and a release just "pops out" at the end, then any of us with an old PowerMac can fire it up, and just execute it. Or actually, you can emulate one with QEMU too these days. Of course you don't want to run it continuously, but to fire the emulated machine up, do a build, upload it somewhere and shutting it down should be perfectly doable for any reasonably fast host, even headless.

Charlie

Op 2021-04-19 om 07:52 schreef Karoly Balogh via fpc-pascal:

Doc upload also is a bottleneck.

It is not the work to those tiers that keeps up, but unforeseen things happening while doing that, because nobody tests them inbetween releases, and things pop up last minute.

If you have automated systems, but nobody pays attention to them till just before release time, you get the same problem.

That doesn't mean I'm against automation. The problem is just more than that, which is why I hope to moving to a bi-annual release scheme would be best.  It would reduce the need for this or that fix to get in last minute, and somewhat grease the wheels of releasing.

Major releases can be a pain, minor releases should be reasonably effortless.

In my experience, MacOS is not well-behaved in VMs, but admittedly it's been a while since I last tried.

But that does not solve the manual formatting.

Don't get me wrong, I am all for automating as much as possible, but if a tool requires an old macos, and manually formatting files, my first reaction is to look for another tool.

Michael.

Michael Van Canneyt wrote

From what you say, both problems are related to the tool you use. Are there no other tools that can be used ?

The wrapping problem is unrelated to the tool, but to the console mode focus of our installation files. Such a manually formatted text file is simply unsuitable for a GUI installer.

Jonas

But if the tool didn't wordwrap, all would be OK, no ?

Michael.

It's not the tool, it doesn't touch the files. It's the GUI of the installer application, which shows a plain window that happens to be slightly too narrow relative to our chosen line length (depending on the kind of characters on the line, as it uses a proportional font).

Jonas

So it's the MacOS installer window that does the wrapping ? being used to Inno Setup I automatically assumed the tool also does the GUI...

That explains it. Thanks.

Michael.

But couldn’t we just wrap ourself in all installers if needed? This should be a no brainer, no?

I think the point is more to get a release where everything works and is tested. Running make into is no problem but the quality of the resulting installer might be less than that we currently have.