Central Portal logistics #821
Closed
rossabaker
started this conversation in
Ideas
Replies: 3 comments 1 reply
|
Personally, SNAPSHOTs are quite important for me in terms of orchestration between different libraries and benchmarking changes reproducibly. I'm very much in favour of retaining snapshots. Ripping the bandaid off and making breaking changes will allow us to do this cleanly with less chance of bugs, so 3 seems the right option. With 2, I agree these things sound like a stretch. |
1 reply
|
Test release, based on Option 3: https://central.sonatype.com/artifact/com.rossabaker/sbt-typelevel_2.12_1.0/0.8.0-rab.1 Not published to |
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
The deadline to move to Central Portal is looming. http4s is moving successfully with an org plugin, built on sbt-typelevel, built on sbt-sonatype.
We could follow the same roadmap here. We'd need to change the default host in sbt-typelevel, along with making sure all projects are publishing on Java > 8, even as
tlJdkRelease := Some(8). We'd also lose snapshot publishing. I question the value of those, but other people love them.sbt-1.11.0 brings improved Central Portal technology. This should address both the snapshot problem and the JDK problem.
I see three options:
org.http4sdid.🏆 Option 3 (PR) is cleanest, but is a breaking change. Then again, Sonatype is imposing a breaking change on all open source authors next month anyway.
Option 2 is the highest effort and propagates cruft, but could arguably be a patch release, if we consider sbt-1.11.0 and a change to the default publishing host "patches." This is a stretch.
Option 1 could definitely be a patch release, but forces snapshotlessness and jdkelevenness on everyone.
All reactions