Release policy

[nedtwigg]

We have JitPack setup, so you can grab any commit you want at any time, see these instructions.

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).

[fkleedorfer]

I would welcome a release because I contributed a new formatter for RDF (#2261) and I would love to start using it. The last release was made 40 days ago.

[jGleitz]

We would welcome a release so we can switch back to the main release track of spotless and keep our fix for the ERESOLVE errors we were facing. The last release was 33 days ago.

[jochenberger]

@nedtwigg, I'd appreciate a release soon. Specifically, I think there is some demand for https://github.com/diffplug/spotless/pull/2345 now that Java 25 is out. See also https://github.com/diffplug/spotless/issues/2468. FTR, it's been 64 days since the last release.

[nedtwigg]

thanks @jochenberger, will do! We've got one last PR to review and merge and then it's off to the presses

• https://github.com/diffplug/spotless/pull/2633