Automated snapshot publishing for guardrail modules

[ptrdom]

Currently snapshots are not published in between releases, it would be neat to have them for early adoption of new features.

Looking at the release process, I do not think it is possible to implement snapshots without changes to it, because each module being released separately does not play well with automation of tools like sbt-ci-release and sbt-dynver, because it is difficult to determine which modules in the sbt project change and which of them require version bumps in an automated way.

Having this in mind, I see only two ways to implement snapshots:

1. Release whole repository under a single version.
   • Use https://github.com/sbt/sbt-ci-release and https://github.com/scalacenter/sbt-version-policy to set it all up
     • https://github.com/scalacenter/sbt-version-policy#how-to-integrate-with-sbt-ci-release
     • https://github.com/scalacenter/sbt-version-policy#how-to-integrate-with-sbt-dynver
   • This is likely how all Scala OSS projects that have automated publishing of both releases and snapshots do it.
   • Version policy becomes project-wide, kind of looses its meaning.
2. Split modules up to their own repos.
   • Implement separate release processes with https://github.com/sbt/sbt-ci-release and https://github.com/scalacenter/sbt-version-policy.
   • Too much of a hassle during development.
     • Might work okay with git submodules.
   • Not my personally preferred route.

Since there are tradeoffs in proposed changes, I guess the question is - manual release process with correctly enforced version policy for all modules or having automated snapshot publishing, which of these is more beneficial? I am obviously leaning towards the latter, but I might be missing some details on why release process for guardrail is the way it is now.

Thoughts?

[blast-hardcheese]

Thank you for the writeup!

A single version was causing unnecessary version bumps and CI hours wasted for users, bumping a Java module shouldn't cause a version bump PR for Scala users and vice versa.

Split modules may be coming soon, but I'm still holding on as long as I can, since loading the entire project int a single sbt instance is still very convenient. (It may be possible to still load them all into a single runtime by way of ProjectRef, but I haven't attempted that yet).

All that being said, however, reading through your links got me to realize that I think we were only limited by useReadableConsoleGit (until sbt/sbt-git#238 is merged, at least!) as well as a parameter to the release action. We're already using sbt-ci-release, and I've done all the work to get the module version derived by tag, so it might just work.

[blast-hardcheese]

Hmm. I didn't close that intentionally.

[blast-hardcheese]

Ok. Manual snapshots cut, for now at least.

[info] guardrail-core / version
[info] 	0.75.3-SNAPSHOT
[info] guardrail-scala-support / version
[info] 	0.75.3-SNAPSHOT
[info] guardrail-scala-http4s / version
[info] 	0.76.1-SNAPSHOT
[info] guardrail-scala-akka-http / version
[info] 	0.76.0-SNAPSHOT

NB: You need to explicitly libraryDependencies ++= Seq(...) all of these in your project/guardrail.sbt, since the ABI has been broken as we work up to 1.0.

Closing this for now, after confirming that the snapshot for guardrail-core was published to s01.oss.sonatype.org.