https://kotlinlang.org logo
Join Slack
Powered by
Anyone have thoughts on <Maven Central Portal not ...
# library-development
e
Anyone have thoughts on Maven Central Portal not allowing SNAPSHOTS? I'm not a fan, and I use SNAPSHOTS specifically for the reason they call out for SNAPSHOTS being "bad" 😆
it has the side effect of users being able to make their pre-release versions available to their communities during ongoing development
I feel like that's a very valuable tool, since it makes it very easy for the community to verify that something works, or adopt changes before a release is made. It's probably not the best solution for this, and a full release pipeline would probably be "better", but I think that's unfeasible for small projects that don't have the manpower to setup and manage those types of solutions.
➕ 3
e
I don't see what makes snapshots easier than (alpha) releases - isn't the same publishing steps?
e
With alphas I need to either build the infrastructure to bump the alphas, or do it manually. It can also cause the alpha version to get kind of high; I release a SNAPSHOT every time I merge a PR
➕ 4
m
+1 also I don't want to pollute the MavenCentral immutable vault with gazillions of untested versions
You can always setup your own repo for SNAPSHOTs but it was somewhat handy to have sonatype do it
e
Right, it was very convenient to have Sonatype do it. It would be nice if they would reconsider...
➕ 3
m
Want to send them a support request?
e
I did 😢
💙 1
They responded that this is the way it will be for now
😢 1
m
Damn. We could do a community replacement but it’s never going to as convenient as they have the namespace verification 😕
e
From their message it sounds like they weren't committing to not bringing it back, so I'm hopeful. I've toyed with using jitpack as a replacement for SNAPSHOTS, and that alone should make them bring it back 😈
💯 1
🤞 1
m
A signal we can send is ask for namespaces to be downgraded to S01. I think they have a process for that. If enough people ask that might tip the scale
e
That would only be for new namespaces though, right?
m
Yes but the old ones can stay on S01 forever ?
e
I'm hoping that this will be conclusively decided (in one direction or another) before they do the migration.
👍 1
c
it has the side effect of users being able to make their pre-release versions available to their communities during ongoing development
No, that's not true, you can release 
1.2.0-alpha.1
versions. What you can't do is release mutable versions, and I think that's a very good thing. As a user, I may accept working with pre-release versions in my projects, but I'm never touching a mutable version: I don't even know if the same code is going to run on my machine, in CI, and later in production!
Publishing a pre-release version doesn't have to be more complex than publishing any other version. If you automated regular versions, you can just use the same config. You can use 
git describe
to get a unique version number if you want to automatically publish all PRs
m
But mutable versions have some value, right? No need to flood Maven Central with tons of pre-release versions?
It’s 44TB right now, I don’t want to think how big it’ll be if everyone starts releasing immutable jars on every commit
➕ 1
c
Do they? If you use Gradle, and you use any of these features, mutable versions lead to incoherent executions: • incremental compilation • the build cache • the configuration cache (for snapshots of plugins)
m
mutable is for quickly trying out something, never run it in production nor commit it to your repo but it has saved me in a couple of occasions where asking a community member to git clone and use an included build was not an option
➕ 2
c
I don’t want to think how big it’ll be if everyone starts releasing immutable jars on every commit
I mean, that's what many people do already. Look at any KotlinX library, especially Compose
sad panda 1
m
Is it on every commit?
🚫 1
c
That use-case is exactly what included builds are for, though… I'm curious in which situation you can't use them. Publishing should only be when you want people to use it
m
Everyone knows how to add maven coordinates. Asking users to clone and include build is a lot more effort
➕ 1
Not to mention some included build breaks with configuration cache or whatever Gradle fun stuff
e
JB publishes pretty much every build to their own repo
👍 1
m
Yea, own repo is fine
c
I'm a GitLab user, what I do is: • publish all PRs to GitLab's maven repository. You have to add it to your gradle config, but that's it • publish all alpha/beta/stable releases to Central
e
I would 100% use that instead of any mutable versions in a public repo
m
I’m probably going to do this as well with a GCP bucket or what not but now every maintainer has to setup their own publishing host
It was kind of convenient to have Sonatype provide that for us
(although I get the point about tagged vs mutable)
c
m
GitHub requires authentication, that’s a hard pass
c
I don't use GitHub, but if it's anything like on the GitLab side, it's 3 lines in your CI and you're done
lol really?
👌 1
well, you could setup a GitLab mirror that does this automatically for you. If you want, I could show you how, it's really simple, all of this is in the free plan
m
Agreed there are solutions but they all come with additional friction compared to the status quo
e
jitpack still exists
m
Can you customize the version with jitpack (like setting the sha1 in the version)?
If the project doesn’t have any GitHub Releases you can use the short commit hash or ‘master-SNAPSHOT’ as the version.
Yup
c
But anyway, mutable versions == the ability to delete versions, and that's against everything Central stands for…
m
jitpack year is 2024! They were just too early 😂
the ability to delete versions, and that’s against everything Central stands
It’s 2 different things. Central is for production, SNAPSHOTs is for development
e
I wouldn't use snapshots beyond mavenLocal/etc.
nod 1
m
Agreed, I would never commit a 
-SNAPSHOT
version to a repository of mine
(famous last words 😅 )
GitHub requires authentication, that’s a hard pass
I’m now thinking about hosting a maven repo in github pages 🙃 ....
🙃 1
👀 1
e
@ephemient @CLOVIS everything you are saying is correct, it just adds a lot of friction to the process for producers and consumers that use SNAPSHOTS in their workflow.
e
I'm now thinking about hosting a maven repo in github pages 🙃 …
https://github.com/github/maven-plugins#site-plugin they did publish a (very old) maven plugin to do that
🚀 2
a
I’m now thinking about hosting a maven repo in github pages
GitHub Pages has a size limit, but you can host a repo in a disconnected git branch https://github.com/krzema12/snakeyaml-engine-kmp/tree/artifacts
👍 1
Open in Slack
PreviousNext
Powered by