[fpc-pascal] Separate release cycle for RTL and compiler proposal

[Zamrony P. Juhara via fpc-pascal]

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

[Sven Barth via fpc-pascal]

Post by Zamrony P. Juhara via fpc-pascal
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?

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

[Karoly Balogh via fpc-pascal]

Hi,

Post by Sven Barth via fpc-pascal

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?

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.

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

[Michael Van Canneyt via fpc-pascal]

Post by Karoly Balogh via fpc-pascal
Hi,

Post by Sven Barth via fpc-pascal

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?

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.

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.

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

But MacOS is a problem.

Michael.

[Jonas Maebe via fpc-pascal]

Post by Michael Van Canneyt via fpc-pascal
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
_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
https://lists.freepascal.org/cgi-

[Michael Van Canneyt via fpc-pascal]

Post by Jonas Maebe via fpc-pascal

Post by Michael Van Canneyt via fpc-pascal
But MacOS is a problem.

macOS is also perfectly scriptable, I just have to finish automating it.

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.

Post by Jonas Maebe via fpc-pascal
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).

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.
_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
https://lists.freepasc

[Karoly Balogh via fpc-pascal]

Hi,

Post by Michael Van Canneyt via fpc-pascal

Post by Jonas Maebe via fpc-pascal
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).

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 ?

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.

Post by Michael Van Canneyt via fpc-pascal
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
_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listin

[Michael Van Canneyt via fpc-pascal]

Post by Karoly Balogh via fpc-pascal
Hi,

Post by Michael Van Canneyt via fpc-pascal

Post by Jonas Maebe via fpc-pascal
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).

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 ?

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.

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.
_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pasca

[Jonas Maebe via fpc-pascal]

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
_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
https://lists.freepascal.org/cgi-bi

[Michael Van Canneyt via fpc-pascal]

Post by Jonas Maebe via fpc-pascal

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.

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

Michael.
_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
https://lists.freepa

[Jonas Maebe via fpc-pascal]

Post by Michael Van Canneyt via fpc-pascal

Post by Jonas Maebe via fpc-pascal

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.

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

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
_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[Michael Van Canneyt via fpc-pascal]

Post by Jonas Maebe via fpc-pascal

Post by Michael Van Canneyt via fpc-pascal

Post by Jonas Maebe via fpc-pascal

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.

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

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).

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.
_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/ma

[Florian Klämpfl via fpc-pascal]

Post by Michael Van Canneyt via fpc-pascal

Post by Jonas Maebe via fpc-pascal

Post by Michael Van Canneyt via fpc-pascal

Post by Jonas Maebe via fpc-pascal

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.

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

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).

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.

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

[Marco van de Voort via fpc-pascal]

Post by Karoly Balogh via fpc-pascal

Post by Sven Barth via fpc-pascal
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.

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.

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.

_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
https://lists.freepascal.org/c

[Florian Klämpfl via fpc-pascal]

Post by Karoly Balogh via fpc-pascal
Hi,

Post by Sven Barth via fpc-pascal

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?

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.

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.

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.

_______________________________________________
fpc-pascal maillist - fpc-***@lists.freepascal.org
https://lists.freepascal.org/cgi-bin