What are your practices for SNAPSHOT releases?

# library-development

[CLOVIS]

What are your practices for SNAPSHOT releases?

[CLOVIS]

At #C078Z1QRHL3 :
• Proper releases are Git tag. They are published to MavenCentral and to our GitLab registry.
• All commits on main are published to our GitLab registry, with a retention of a few weeks.
• We don't use MavenCentral snapshots

[mbonnin]

Depends the repos. I usually keep publishing to Maven SNAPSHOTs but mostly to not break people workflows.
I also publish in parallel to a repo where I control the retention. Gives me more confidence when I need to pin something for a few weeks.

[joseph_ivie]

Git tag = proper release
Build number + git shorthash = internal release
A plain -SNAPSHOT is madness and I'm so glad we haven't done that for years now.

[CLOVIS]

Yeah. Our main deployments use git describe to get a unique version number. We have no real -SNAPSHOT versions.

[joseph_ivie]

Well, that's solid confirmation for me we picked the right way to do it!

[CLOVIS]

I personally really dislike mutable artifacts

[joseph_ivie]

We paid the price for them internally several times over before I made the call to switch.

I'm not a smart man, but we learned.

[simon.vergauwen]

Arrow-kt used to have incrementing alpha/beta/RC where alpha was basically a SNAPSHOT release published to maven central but that's out of the question with new cental quota's 😅

Ktor has -eap.build-number which is hosted on a Space repository not central.

[joseph_ivie]

@CLOVIS Did you guys manually program your logic for this? We had to put it in our own Gradle plugin, and if you're doing it too, perhaps we should collaborate on making that a small library

[CLOVIS]

It's the base plugin in OpenSavvy's conventions: gitlab.com/opensavvy/…/base?ref_type=heads

The OpenSavvy conventions are not in MavenCentral (chicken-and-egg problem), you can access them by configuring the repository first:

maven {
			name = "opensavvy-gradle-conventions"
			url = uri("<https://gitlab.com/api/v4/projects/51233470/packages/maven>")

			metadataSources {
				gradleMetadata()
				mavenPom()
			}

			content {
				@Suppress("UnstableApiUsage")
				includeGroupAndSubgroups("dev.opensavvy")
			}
		}

The version is computed using this GitLab CI snippet: gitlab.com/opensavvy/ci-templates/-/blob/…/version.gitlab-ci.yml?ref_type=heads

And then the publishing goes there: https://gitlab.com/opensavvy/playgrounds/gradle/-/blob/main/.gitlab-ci.yml?ref_type=heads#L34

[joseph_ivie]

you know, that looks a heck of a lot less cursed than the way we did it...
We had some code we called in build.gradle.kts.
I think I'll do something similar.

Then again, ours worked very conveniently for local builds

[CLOVIS]

Mine defaults to DEV so it works fine for local builds too

[joseph_ivie]

As in the whole version is DEV? Ours does a version bump from what it would have been and appends a -local to the end of the version

[CLOVIS]

The version is passed by the CI as a Gradle property. Gradle doesn't compute the version itself because that slows down stuff too much

[joseph_ivie]

Indeed it does, it makes my build slower and I hate it. I just didn't think of using CI scripts to do it, for some reason.

[CLOVIS]

So, locally, it's just DEV but you can pass -PappVersion=whatever to override it, which is good enough for my use-cases

[joseph_ivie]

Cool, thank you! I'm going to take that solution. Feels a lot more proper, for sure.

[CLOVIS]

It's also guaranteed to work with configuration cache, project isolation, etc, which is a lot harder to do if you run git within the build scripts 😅

[joseph_ivie]

Unfortunately, I am well aware. Lol