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 <maxle...@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, 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? >> >>
signature.asc
Description: OpenPGP digital signature
