Release policy

[nedtwigg]

The whole point of Spotless is that formatting should not matter. If your formatting plugin is creating "new release" notifications every week then formatting is taking up more time in the ecosystem than it should.

• if you want a release
• and it has been more than 30 days since the last release
• comment here in this issue with
  • why you want a release
  • the number of days since the last release
• and that will kick my butt and I'll do the release

Please don't spam other issues with comments related to "release please!". Keep that here.

[Goooler]

And we can publish snapshots on main branch, users can try out them as a workaround. I did this on

https://github.com/GradleUp/shadow/blob/5bcdb171394bb42adad80b6acd650bb71eafeeff/.github/workflows/ci.yml#L27-L44

[nedtwigg]

Excellent point @Goooler. We have JitPack setup, you can grab any commit you want at any time, see these instructions.

[Goooler]

We should get rid of using jitpack. We are using io.github.gradle-nexus.publish-plugin to publish maven artifacts to MavenCentral, MavenCentral's snapshots also support snapshot Gradle plugins. I'll send a PR later.

https://github.com/diffplug/spotless/blob/4552da0f3535e0ac74ffe3ec7f3e813621c5d023/gradle/java-publish.gradle#L19-L29

[Goooler]

There are few thing to do:

• Get rid of jitpack.
• Would prefer com.vanniktech.maven.publish over io.github.gradle-nexus.publish-plugin, I tried to migrate this but there are so many complex logic should be removed or cleaned up. More details about this point:
  • Provides non-encrypted credentials on CI like https://vanniktech.github.io/gradle-maven-publish-plugin/central/#__tabbed_5_2.
  • Disable refresh and changelog tasks for snapshots.
  • We have to update the version names to snapshots after each release.
• Publish snapshots on main branch.

Some work has been addressed in #2236.

[nedtwigg]

I don't like -SNAPSHOT, because they change out from under you. Easy to end up with commits in history which can't be run in the future because the -SNAPSHOT has changed. That said, I'm fine with adding support for them if you want them.

I love JitPack, because it's only a tiny bit harder to grab HEAD, but I know exactly which commit I'm getting, and I can even commit it and know that my old commits will be buildable / repeatable in the future.

Swapping gradle-nexus.publish-plugin for vanniktech definitely sounds great, and I'd be fine with adding -SNAPSHOT as an option.

[Goooler]

You can always pin snapshots on a specific version like

pluginManagement {
  repositories {
    maven("https://oss.sonatype.org/content/repositories/snapshots/")
  }
}

plugins {
  id("com.gradleup.shadow") version "8.3.0-20240808.050945-5" // a snapshot of 8.3.0
}

[nedtwigg]

Figuring out which code is generating that snapshot is ambiguous. If it can be added without throwing out our current release pipeline, I'm okay with it, but I still think JitPack is a strictly better option for this usecase.

[lukebemish]

You can always pin snapshots on a specific version like

pluginManagement {
  repositories {
    maven("https://oss.sonatype.org/content/repositories/snapshots/")
  }
}

plugins {
  id("com.gradleup.shadow") version "8.3.0-20240808.050945-5" // a snapshot of 8.3.0
}

Please note that this does not work with how gradle plugins are resolved without extra steps! Remember that when you depend on a plugin by id, it actually resolves the module <plugin id>:<plugin id>.gradle.plugin:<plugin version> -- so in this case, com.gradleup.shadow:com.gradleup.shadow.gradle.plugin:8.3.0-20240808.050945-5. That module itself is only a single metadata file, and actually has a dependency on some other module where the plugin is actually located -- com.gradleup.shadow:shadow in this case -- and that single pinned snapshot version has a generic -SNAPSHOT dependency on the actual module, as com.gradleup.shadow:shadow:8.3.0-SNAPSHOT, and it'll pull i nthe latest snapshot anyways. So, if you want to pin a gradle plugin to a single snapshot version instead of just the latest snapshot, you have to pin both the plugin that you depend on by ID, and the actual module the plugin is located at, through a dependency in a buildscript block (I found this out the hard way, unfortunately).

[Goooler]

No need to add an extra resolution strategy if you have published plugin markers. This is why I want to migrate to vanniktech in #2236, it will publish both plugin coordinates and markers.

[lukebemish]

I wasn't talking about resolution strategies. If both plugin markers and the actual plugin are published with -SNAPSHOT versioning, then you'll still have the issue of pinning the plugin marker (via pinning the plugin when you depend on it by ID) transitively pulling in an unpinned actual plugin jar, which is what I was talking about. -SNAPSHOT versions are just inherently rather painful with how the plugin marker works.