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 <s...@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?
>

Reply via email to