Closed SethTisue closed 4 years ago
not sure if you want to make a 3.0.x branch, or just let 3.0.x development proceed on the default work
branch
do you want to do a 3.0.0-M1 or a 3.0.0-RC1, or just go straight to 3.0.0? the main difference would be that users will expect 3.0.0 to lock bincompat
I think, since it makes sense to publish the new stable version 2.2.0, it should be just merged into work
, and from there straight into main
. I also find it easiest to remember that main
has the latest stable (non-SNAPSHOT) version. So perhaps merge to work
, then I tag v2.2.0
, then merge to main. I don't think we need a dedicated 3.0.x branch.
gah, I forgot that we had both work
and main
in this repo
I'm fine with whatever you decide
Yes, since scala-swing is not officially supported, the cycle from major version to major version is faster, we didn't even have a 2.1.x
branch. So I'd suggest to keep it simple and merge to work
and once released back to main
.
It's important that the artifacts released to maven are built on JDK 8 not 11; because there might be some API changes in Java, so to be on the safe side. I don't think we need to enforce JDK 6 for Scala 2.11 any longer.
It's important that the artifacts released to maven are built on JDK 8 not 11; because there might be some API changes in Java, so to be on the safe side.
agree. the isReleaseJob
logic in build.sh
ensures that.
I don't think we need to enforce JDK 6 for Scala 2.11 any longer.
agree
I think artifacts have been staged at sonatype: https://travis-ci.com/github/scala/scala-swing/builds/199608189
We ended up with four staging repos, all containing 2.13 artifacts only. I dropped them
Let's merge #127 and try again
Okay, let's try again. You can either delete and recreate the 3.0.0 tag, or just push a 3.0.1 tag 🤷♂️
I won't be surprised if we need to do at least one more round of this, but 🤞
ok, will delete and re-push
dammit
2020-11-10 18:12:51.962Z info [SonatypeService] sonatypeProfileName : org.scala-lang - (SonatypeService.scala:25)
2020-11-10 18:12:51.995Z error [Sonatype]
java.io.IOException: Supplied file /home/travis/build/scala/scala-swing/target/sonatype-staging/3.0.0 is a not an existing directory!
at org.sonatype.spice.zapper.fs.AbstractDirectory.<init>(AbstractDirectory.java:32)
at org.sonatype.spice.zapper.fs.DirectoryIOSource.<init>(DirectoryIOSource.java:68)
at org.sonatype.spice.zapper.fs.DirectoryIOSource.<init>(DirectoryIOSource.java:59)
I don't know what this is. I'm out of time, I'll have to look at it a bit later
Google brings up this, which might be the same cause: https://github.com/xerial/sbt-sonatype/issues/103
Might be worth an attempt to revert to sbt 1.3 ; I think there are quite a few things that are different and/or not yet ironed out in 1.4.
Looking into build.sh
and comparing with the one of scala-xml, we might just set projectPrefix="swing/"
and can remove the publish / skip := true
for the other sub-projects AFAICS. that might also clear up any strangeness with regard to the synthetic root project? Should I try that?
Ok, almost there: https://travis-ci.com/github/scala/scala-swing/builds/200029393
Of course dottydoc was giving us the middle finger in the last moment. I don't know why it's not even disabled by default. It essentially never works. I will disable dottydoc and push again.
All green, check contents at sonatype.
released — artifacts should arrive at e.g. https://repo1.maven.org/maven2/org/scala-lang/modules/scala-swing_2.13/3.0.0/ soon
Thanks for figuring this out.
Over at https://github.com/scala/scala-swing/releases , looks like there's a draft release which can be deleted, and then release notes added to https://github.com/scala/scala-swing/releases/tag/v3.0.0
@Sciss we don't have good docs on that, but there is a ticket where we accumulate knowledge: https://github.com/scala/sbt-scala-module/issues/16
in short, if you push a release tag, sbt-ci-release will cause Travis-CI will publish to Sonatype staging. then you notify me and I release it to Maven Central.