Platform Packages vs. Git Branches
I’ve always supported multiple platforms (e.g. different Pharo versions) via packages like MyProject-Plaform-Pharo9. Thinking back, the primary reason is that is how I saw it done by other projects. Also, I adopted the practice well before git was in wide use in the Pharo world.
However, Jan Bliznicenko recently suggested an alternate workflow which sounds like how Pharo itself is managed: use git branches, with the primary branch supporting only latest Pharo, and other branches only getting critical bug fixes backported.
Not sure how that would work for projects that support other dialects e.g. Gemstone and Squeak, since there would then be multiple “latest versions”.
I’m interested in opinions about these options as I feel that Magritte is an important community asses and want to keep it compatible on as many platforms as possible (with as little work as possible)! I also get the feeling that many people keep ancient systems in production, and I wonder which they would prefer - a project that is stable on a Pharo version (more or less) when that version is released or having the latest commits, especially bug fixes.
Thoughts?
My thought is that the “Git way” would be to have an “abstract” project for the shared code and separate “concrete” projects for each of the dialects. Within each dialect-specific project include the shared code as a submodule. See https://stackoverflow.com/questions/12883543/how-to-organize-cross-platform-projects-with-git-repository.
On Aug 25, 2022, at 4:16 PM, sean@clipperadams.com wrote:
I’ve always supported multiple platforms (e.g. different Pharo versions) via packages like MyProject-Plaform-Pharo9. Thinking back, the primary reason is that is how I saw it done by other projects. Also, I adopted the practice well before git was in wide use in the Pharo world.
However, Jan Bliznicenko recently suggested an alternate workflow which sounds like how Pharo itself is managed: use git branches, with the primary branch supporting only latest Pharo, and other branches only getting critical bug fixes backported.
Not sure how that would work for projects that support other dialects e.g. Gemstone and Squeak, since there would then be multiple “latest versions”.
I’m interested in opinions about these options as I feel that Magritte is an important community asses and want to keep it compatible on as many platforms as possible (with as little work as possible)! I also get the feeling that many people keep ancient systems in production, and I wonder which they would prefer - a project that is stable on a Pharo version (more or less) when that version is released or having the latest commits, especially bug fixes.
Thoughts?
I have some thoughts...
Depending upon the pace of relative development keep in mind that merging
changes between platform branches could present interesting problems
whereas the package-based approach allows one to copy a method (if the
algorithm is too platform-specific --- this the area where merging gets
interesting, especially if there are a number of methods involved), or a
class (if the class needs to be replaced on a platform by platform basis)
or insert extension methods and/or supplementary classes with relative
ease...
Also, keep in mind that CI on GitHub is a critical component of
cross-platform project support. Over the years being able to rely on Travis
runs to highlight platform specific issues in a PR is extremely valuable to
keeping the port up-to-date --- it helps reinforce the cross-platform
nature of the project for contributors and allows platform maintainers to
be involved in the process while the iron is hot ... If Github actions can
be written that would run actions for multiple branches on the basis of a
PR on a different branch, then this "requirement" might be satisfied.
In the very early days of using github and Smalltalk, I used the branch per
platform approach for FileTree[1] (so it was the first multi-platform
project for me) ... and if you look at the network graph[2], jump to the
end and scroll backwards, you will find that the merges between branches
stopped in the very early days and in the end they were effectively two
separate projects (in more ways than one) that diverged quite a bit over
time. The big problem with that effort was there was never a good
definition of the common code base and the "common code" diverged over time
to the point where a merge was not feasible ... We didn't have cross-branch
CI with travis-ci so I imagine that the experiment my have turned out
better if the platform branches and most importantly the common code, could
have been been kept in synch by concurrent testing ...
If multi-branch CI is possible the major sticking point would be the
"automatic merge" that would be required in the case of merge conflicts ...
and this becomes a bigger issue when the developer of the contribution does
not have the ability to run local tests of manually merged conflicts
(yikes) ... with a package-based approach if a test fails due to
platform-specific issue, a topic branch for the issue can be created and
the original contributor and a platform expert can collaborate on a
solution on the same topic branch until the tests are passing ... this is
basically the approach that has been taken with all of the multi-platform
projects that I've been involved in over the last decade and it "works" ...
not perfect by any means, but certainly functional ...
Dale
[1] https://github.com/dalehenrich/filetree
[2] https://github.com/dalehenrich/filetree/network
On Thu, Aug 25, 2022 at 7:16 AM sean@clipperadams.com wrote:
I’ve always supported multiple platforms (e.g. different Pharo versions)
via packages like MyProject-Plaform-Pharo9. Thinking back, the primary
reason is that is how I saw it done by other projects. Also, I adopted the
practice well before git was in wide use in the Pharo world.
However, Jan Bliznicenko recently suggested an alternate workflow which
sounds like how Pharo itself is managed: use git branches, with the primary
branch supporting only latest Pharo, and other branches only getting
critical bug fixes backported.
Not sure how that would work for projects that support other dialects e.g.
Gemstone and Squeak, since there would then be multiple “latest versions”.
I’m interested in opinions about these options as I feel that Magritte is
an important community asses and want to keep it compatible on as many
platforms as possible (with as little work as possible)! I also get the
feeling that many people keep ancient systems in production, and I wonder
which they would prefer - a project that is stable on a Pharo version (more
or less) when that version is released or having the latest commits,
especially bug fixes.
Thoughts?
Hi Sean,
At some point you will probably come to the same point that Seaside and Fuel have reached in the past: build your own abstraction layer (Grease in Seaside, Fuel-Platform in Fuel). There are valid arguments against this approach but, personally, I didn't have another choice for Fuel.
Fuel setup:
- A Fuel-Plaform-Core package
- 1 Fuel-Platform package per dialect and version
- development branch, old "release" branch, current "release" branch for Fuel-Platform
- 1 Git branch for Fuel per version
- some magic in the baselines to get Metacello to load what I want
I used to have the same multiple package approach that you mentioned but it fell apart when I had too many packages with too many differences.
Cheers,
Max
On 25 Aug 2022, at 16:16, sean@clipperadams.com wrote:
I’ve always supported multiple platforms (e.g. different Pharo versions) via packages like MyProject-Plaform-Pharo9. Thinking back, the primary reason is that is how I saw it done by other projects. Also, I adopted the practice well before git was in wide use in the Pharo world.
However, Jan Bliznicenko recently suggested an alternate workflow which sounds like how Pharo itself is managed: use git branches, with the primary branch supporting only latest Pharo, and other branches only getting critical bug fixes backported.
Not sure how that would work for projects that support other dialects e.g. Gemstone and Squeak, since there would then be multiple “latest versions”.
I’m interested in opinions about these options as I feel that Magritte is an important community asses and want to keep it compatible on as many platforms as possible (with as little work as possible)! I also get the feeling that many people keep ancient systems in production, and I wonder which they would prefer - a project that is stable on a Pharo version (more or less) when that version is released or having the latest commits, especially bug fixes.
Thoughts?
Max,
Yeah, your approach looks manageable ... with a well defined common code
base, both branch per platform (fuel) and platform packages (Grease) can be
used ...
I looked at your github action code and see that you've got a solution for
triggering multi-branch runs ... workflow per branch/platform ... so I will
HAVE TO CONSIDER the branch per platform approach again :)
Dale
On Mon, Aug 29, 2022 at 8:53 AM Max Leske maxleske@gmail.com wrote:
Hi Sean,
At some point you will probably come to the same point that Seaside and
Fuel have reached in the past: build your own abstraction layer (Grease in
Seaside, Fuel-Platform in Fuel). There are valid arguments against this
approach but, personally, I didn't have another choice for Fuel.
Fuel setup:
- A Fuel-Plaform-Core package
- 1 Fuel-Platform package per dialect and version
- development branch, old "release" branch, current "release" branch
for Fuel-Platform
- 1 Git branch for Fuel per version
- some magic in the baselines to get Metacello to load what I want
I used to have the same multiple package approach that you mentioned but
it fell apart when I had too many packages with too many differences.
Cheers,
Max
On 25 Aug 2022, at 16:16, sean@clipperadams.com wrote:
I’ve always supported multiple platforms (e.g. different Pharo versions)
via packages like MyProject-Plaform-Pharo9. Thinking back, the primary
reason is that is how I saw it done by other projects. Also, I adopted the
practice well before git was in wide use in the Pharo world.
However, Jan Bliznicenko recently suggested an alternate workflow which
sounds like how Pharo itself is managed: use git branches, with the primary
branch supporting only latest Pharo, and other branches only getting
critical bug fixes backported.
Not sure how that would work for projects that support other dialects e.g.
Gemstone and Squeak, since there would then be multiple “latest versions”.
I’m interested in opinions about these options as I feel that Magritte is
an important community asses and want to keep it compatible on as many
platforms as possible (with as little work as possible)! I also get the
feeling that many people keep ancient systems in production, and I wonder
which they would prefer - a project that is stable on a Pharo version (more
or less) when that version is released or having the latest commits,
especially bug fixes.
Thoughts?
On 29 Aug 2022, at 18:25, Dale Henrichs wrote:
Max,
Yeah, your approach looks manageable ... with a well defined common code
base, both branch per platform (fuel) and platform packages (Grease) can be
used ...
I looked at your github action code and see that you've got a solution for
triggering multi-branch runs ... workflow per branch/platform ... so I will
HAVE TO CONSIDER the branch per platform approach again :)
Yeah, not perfect, but it works (reusability isn't a focus of GitHub workflows...).
Dale
On Mon, Aug 29, 2022 at 8:53 AM Max Leske maxleske@gmail.com wrote:
Hi Sean,
At some point you will probably come to the same point that Seaside and
Fuel have reached in the past: build your own abstraction layer (Grease in
Seaside, Fuel-Platform in Fuel). There are valid arguments against this
approach but, personally, I didn't have another choice for Fuel.
Fuel setup:
- A Fuel-Plaform-Core package
- 1 Fuel-Platform package per dialect and version
- development branch, old "release" branch, current "release" branch
for Fuel-Platform
- 1 Git branch for Fuel per version
- some magic in the baselines to get Metacello to load what I want
I used to have the same multiple package approach that you mentioned but
it fell apart when I had too many packages with too many differences.
Cheers,
Max
On 25 Aug 2022, at 16:16, sean@clipperadams.com wrote:
I’ve always supported multiple platforms (e.g. different Pharo versions)
via packages like MyProject-Plaform-Pharo9. Thinking back, the primary
reason is that is how I saw it done by other projects. Also, I adopted the
practice well before git was in wide use in the Pharo world.
However, Jan Bliznicenko recently suggested an alternate workflow which
sounds like how Pharo itself is managed: use git branches, with the primary
branch supporting only latest Pharo, and other branches only getting
critical bug fixes backported.
Not sure how that would work for projects that support other dialects e.g.
Gemstone and Squeak, since there would then be multiple “latest versions”.
I’m interested in opinions about these options as I feel that Magritte is
an important community asses and want to keep it compatible on as many
platforms as possible (with as little work as possible)! I also get the
feeling that many people keep ancient systems in production, and I wonder
which they would prefer - a project that is stable on a Pharo version (more
or less) when that version is released or having the latest commits,
especially bug fixes.
Thoughts?