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?