Sure, but for me that does not count for FileLogger. Your approach might be the right way theoretically. But putting a single class with a separate baseline in a separate repository is just overkill. For something like FileLogger I don���t want to have separate versions. It is so basic and fundamental that the only thing necessary is to be able not to load it and that is fine with groups. Furthermore if I change FileLogger and BeaconCore at the same time how can I use the changed versions together? Changing FileLogger to point to BeaconCore master and when I���m done release a new BeaconCore version to point at from FileLogger?
I hope you see that your approach enables certain things and makes others more complicated. So I agree that not every logging client should be in the beacon repo. But there is a line to draw for which it is useful to separate and for which it is not. And for FileLogger it is not useful. Even for syslog I doubt it. For my elasticsearch logger it is of course not the right place and that need to be separate.
Btw. this is kind if a discussion I wanted to have for a long time. We need a definition of what pharo really includes. To me there is the minimal core containing only the necessary things, then there is the pharo eco system that includes all the tools the community provides and maintains. And then there are user projects that is everything else.
FileLogger is surely part of the eco system. Syslog as well
Norbert