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
