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?