Central Portal logistics #821
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. |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
We've chosen Option 3. Follow along here. |
Beta Was this translation helpful? Give feedback.
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.
Beta Was this translation helpful? Give feedback.
All reactions