Releaser

EpMonitor current disable. Metacello new baseline: 'GToolkitReleaser'; repository: 'github://feenkcom/gtoolkit-releaser/src'; load. EpMonitor current enable.

tudor girba — 2022-04-29 at 10:47 via discord I think there are several issues. So, let's take them one by one. That some projects get improved upstream and not adopted downstream, has always been an issue that depended on the policy of the downstream project. *Releaser* will release anything that is in the image as long as you have the right to release in the respective repo. If you don't, a solution is to fork for the purpose of releasing. It works really well. This leads us to projects managed differently. It is because they are managed differently that forking a solution. Today, the projects we depend on are not reproducible in a consistent fashion, yet our code is. This shows that our solution is flexible enough to reach the stated **goal of creating reproducible releases** regardless of how the upstream project is organized. As for the community adopting it, we would only be happy if people want to adopt it.

~

tudor girba via discord — I really do not understand what you mean. There is nothing that happens in typical projects that is not supported in a scenario in which *Releaser* is used. The only difference to others is that other projects update manually and ad-hoc. The only consistently released Pharo project I know is Pharo itself (excluding GT, of course) as it's released automatically. Releaser adds to that, and it knows how to affect a separate branch, too, so that the main branch is not affected in any way. This means that current projects can continue working the way they want. I do not see the drawbacks.