2018-05-26 12:19 GMT+03:00 Norbert Hartl <norb...@hartl.name>: > > > Am 26.05.2018 um 08:41 schrieb Denis Kudriashov <dionisi...@gmail.com>: > > > 2018-05-26 9:30 GMT+03:00 Stephan Eggermont <step...@stack.nl>: > >> Denis Kudriashov <dionisi...@gmail.com> >> wrote: >> > 2018-05-25 20:03 GMT+03:00 Stephan Eggermont >> <step...@stack.nl>: >> > >> >> Denis Kudriashov <dionisi...@gmail.com> >> >> wrote: >> >>> >> >>> Because when you will fix or improve Beacon-SysLog you will probably >> do >> >> not >> >>> want to update Beacon-Core version which will force you to update >> Pharo >> >>> (where SysLog is not loaded). >> >> >> >> I seem to be missing something here. Why would you update the baseline >> for >> >> that? >> >> >> > >> > Question is not about baselines. >> > Separate repositories for Core and loggers are required to version them >> > separately. >> > It will allow users to load Core version 1.1, SysLog version 2.0 and >> > FileLogger 3.0. >> > And it will allow maintainers improve these projects separately. As I >> was >> > described the fix in SysLog will not require updating BeaconCore which >> is >> > included in Pharo. >> >> You do not have a use case for separate repos, but one for duplicates of >> the same repo. > > > If two entities needs separate versioning they should be in separate > repositories. Do you agree with this? > > > 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 >
Ok. I agree > > Norbert > > You need that anyhow because your images depend on different >> branches and versions. You might want to solve that by having only one >> image responsible for source code management, and all others connecting to >> that instead of using libgit directly. >> >> Stephan >> >> >> >> >> >
