Am 26.05.2018 um 08:41 schrieb Denis Kudriashov <dionisiydk@gmail.com>:

2018-05-26 9:30 GMT+03:00 Stephan Eggermont <stephan@stack.nl>:

Denis Kudriashov <dionisiydk@gmail.com>
wrote:
> 2018-05-25 20:03 GMT+03:00 Stephan Eggermont
<stephan@stack.nl>:
>
>> Denis Kudriashov <dionisiydk@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

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