migrate to sbt-ci-release

[kpodsiad]

adapted from: https://github.com/evolution-gaming/scache/pull/164 part of: https://github.com/evolution-gaming/scache/issues/163

Steps which are needed to have easy to use scache on Scala 3:

• [ ] publish cats-helper on maven
• [ ] publish smetrics on maven.

TODO in this PR:

• [x] rename packages to com.evolution to be consistent with new organization name
• [ ] take care of stale coverage badges?

[kpodsiad]

I renamed packages to com.evolution. As there is no cats-helper under com.evolution on maven, after merging this we could start with 1.0.0 or is it better to continue with current version number?

[Z1kkurat]

after merging this we could start with 1.0.0 or is it better to continue with current version number?

I think starting with 1.0.0 would only cause confusion as the change from com.evolutiongaming to com.evolution is a subtle one.

On a side note: what is the motivation for such migration to Sonatype? Keeping our artifacts in external storage makes us depend on it, to which there can be several downsides:

• it's less likely to get cached by our Artifactory as sonatype is queried first when resolving an artifact
• any downtime of sonatype can cause some inconvenience due to the above
• publishing and using immediately becomes hard as sonatype indexes new versions quite slowly, so it can appear there in a matter of hours
• (this is my personal preference) using only tags for marking new versions makes it less convenient to discover what changed between some versions: one would need to know specific versions beforehand to be able to compare them in GH rather than opening the list of commits and read through it with version update commits present along the way

[kpodsiad]

On a side note: what is the motivation for such migration to Sonatype? Keeping our artifacts in external storage makes us depend on it, to which there can be several downsides:

* it's less likely to get cached by our Artifactory as sonatype is queried first when resolving an artifact

* any downtime of sonatype can cause some inconvenience due to the above

* publishing and using immediately becomes hard as sonatype indexes new versions quite slowly, so it can appear there in a matter of hours

I guess main motivation is to trully open source evolution libraries and publishing to maven through sonatype is well estabilished way in JVM ecosystem, tbh I don't know if you can do it in other way. All evo "open-source" libs are being built on developer machine and then published to evolution artifaactory. Personally, I'd never use such lib which isn't being built on github or at least it's not published to maven central because of security reasons. In https://github.com/evolution-gaming/scache/pull/164 there was also a good reason about discoverability and how slightly harder is to use such lib.

Regarding your concerns about long times and incovenience, I've never encountered such issues. I was both publishing and waiting to use newly published artifact, usually it was a matter of minutes rather than hours. Maybe sonatype<->maven improved over time and things are now better than it was few years ago?

(this is my personal preference) using only tags for marking new versions makes it less convenient to discover what changed between some versions: one would need to know specific versions beforehand to be able to compare them in GH rather than opening the list of commits and read through it with version update commits present along the way

I agree with you. I don't know how other people are doing it, but my workflow is following

• push tag to trigger release
• prepare release notes (GH is doing that already for us), select pushed tag and announce release Ability to just trigger release action without creating release on github can be dangerous, but on the other hand how many people have push access to evolutio repostories and are actively contributing (for instance I don't have push access), I guess it can expected from them to create release. But I don't mind removing tags' ability to release too.

---

To sum up, I couldn't care less about publishing to sonatype vs internal artifactory. . But if evolution has really good, battle-tested lib, which currently has no substitute in open soure, then why not to use that situation and gain some publicity among folks? :D

cc: @t3hnar @odomontois as you guys already did this for scache

[Z1kkurat]

Personally, I'd never use such lib which isn't being built on GitHub or at least it's not published to maven central because of security reasons

Is there anything preventing you from building any library locally and publishing to Sonatype manually provided you have the credentials (you're quite likely to have them if you've already set GH publishing up previously for the very same project)? Because of that, I don't think I understand why it addresses possible security issues.

I was both publishing and waiting to use newly published artifact, usually it was a matter of minutes rather than hours. Maybe sonatype<->maven improved over time and things are now better than it was few years ago?

I encountered those issues just recently, a few weeks back when I was publishing the aforementioned scache, hence my concern for that.

Overall, I don't have any objections to publishing to Sonatype (except for the minor commit history inconvenience I mentioned), just wanted to hear your thoughts on the motivation.

[kpodsiad]

The only concern I have is changing the org name given this library is one of the foundational ones, and a lot of stuff is built on top of it

When I think about it, this change shouldn't be disruptive and migration could be gradual. I mean for some time being, there will be com.evolutiongaming-cats-helper and com.evolution-cats-helper, but those libraries will be treated as different ones so there won't be classpath clash between them.

• app X can use old dep as long as it doesn't need new features
• app X can migrate just after release of new lib. If library Y is using old one, it's still fine as they are separate deps with separate fully qualified names. Library Y can migrate on its own
• minor incovenience, IDE will suggest importing from both libs, but that can be a signal for dev to look at this and switch dependency to only one

If I didn't forgot other cases, migration seems to be quite ok, as it's not breaking and must to do 🤔

[Z1kkurat]

We could also make a series/3.x.x branch and back-port any new functionality during the migration period. Thought that would put some maintenance burden in addition to the existing ce2/ce3 branches

[t3hnar]

When I think about it, this change shouldn't be disruptive and migration could be gradual. I mean for some time being, there will be com.evolutiongaming-cats-helper and com.evolution-cats-helper, but those libraries will be treated as different ones so there won't be classpath clash between them.

How are you going to notify users of old lib that there is a new one with different org name?

[kpodsiad]

How are you going to notify users of old lib that there is a new one with different org name?

How did you notify users when cats-helper disappeared from maven central and started to be published on evolution's artifactory? We can do the same method ;)

I guess I'll write message on our company's slack ;) Cats-helper is not publicly available (in easy way) so I doubt that anyone outside evolution uses it. If there is an interested third party though, I can imagine that they start to care about dependency when there is an important reason (scala steward update, bug or feature request). First one can be neglected as they could stay on outdated version, in the later cases I assume that user will visit github page and somehow they will know that lib was migrated. How? For instance we can put section in the readme, or inform them if they will create issue. If cats-helper was available on maven, then I'd put more thoughts about migration, but otherwise it doesn't seem like a important concern.

[t3hnar]

How did you notify users when cats-helper disappeared from maven central and started to be published on evolution's artifactory? We can do the same method ;)

could you please explain this, because I'm not aware of publishing cats-helper ever to maven central.

[kpodsiad]

@t3hnar well I see that artifacts were published from 2019 to 2021, https://mvnrepository.com/artifact/com.evolutiongaming/cats-helper?repo=evolutiongaming. In the last published artifact, homepage is set to very this repo so I assume it is the same cats-helper about which we're talking right now ;)

[t3hnar]

@kpodsiad if I click on any of the versions I can see the following at https://mvnrepository.com/repos/evolutiongaming:

[EvolutionGaming Repository](https://mvnrepository.com/repos/evolutiongaming)

https://dl.bintray.com/evolutiongaming/maven/

bintray.com is not in the list of autoresolved repositories and is not accessed automatically…

[kpodsiad]

@t3hnar back in the days it was common to publish artifacts to bintray, wasn't it? Anyway, I just have assumed that something which is available on maven central, can be downloaded without any additional effort and this led to my half-serious comment ;) As I wrote, it is probably enough to announce this on evolution slack, as I doubt that people outside of evolution are using this library.

My main motivation for this migration was https://github.com/evolution-gaming/scache/issues/163, but if I can be honest, I don't think I have enough will to carry this task on as I don't need it personally. It seems just as a some work in order to achieve something that nobody really wanted explicitly :|

[t3hnar]

As I wrote, it is probably enough to announce this on evolution slack, as I doubt that people outside of evolution are using this library.

I'd recommend to have one more last release with deprecation of major api calls and referencing to new artefact.

It's pity that scache has been released in such a bad manner…

My main motivation for this migration was https://github.com/evolution-gaming/scache/issues/163, but if I can be honest, I don't think I have enough will to carry this task on as I don't need it personally. It seems just as a some work in order to achieve something that nobody really wanted explicitly :|

I completely support you on this noble effort and I think this is a very useful work.

My recent questions were rather caused by confusion after your statement, I seriously thought somebody deployed something manually to maven central…