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 <[email protected]> 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, [email protected] 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? > >
