I see libs prefixing their `alpha` versions with `...

# library-development

[mbonnin]

I see libs prefixing their alpha versions with "0" but not doing it for their releases:
• 3.2.1
• 3.3.0-alpha01
Is there a reason for this? If I read https://docs.gradle.org/current/userguide/single_versions.html#version_ordering correctly, it will also work without the leading "0" , Gradle should consider alpha10 > alpha2 in all cases ?

[Javier]

I think the correct semver is 3.3.0-alpha.1

[mbonnin]

Alright, no one does that 😅

[mbonnin]

From that doc above, I understand Gradle will split parts if they contain both numeric and non-numeric subparts. ie 3.3.0-alpha1 == 3.0.0-alpha.1 ==3.0.0-alpha-1

[Javier]

yeah, it is not usual

[Javier]

Thinking on it, I use dependabot and/or ben manes plugin

[Javier]

I think dependabot has its own mechanism to decide what is the newest version, but not sure if ben manes just use the Gradle implementation to check the order

[mbonnin]

Last time I used ben manes, I had to write some custom rules for alphas, etc...

[Javier]

yeah, I have a regex too, but not for this issue

[Javier]

message has been deleted

[louiscad]

I prefix with zero in case there's more than 9 versions, so your (our) eyes never need to jump if looking into a maven repo in the browser like MavenCentral, or in a filesystem like in MavenLocal.

[Javier]

@louiscad hope they fix the browser sorting...

[Javier]

it is annoying

[Drew Hamilton]

IIRC, SemVer rules treat any alphanumeric part as alphabetical, so alpha10 would come before alpha2. On the other hand, SemVer does recognize fully numeric parts as numeric, so alpha.10 would come after alpha.9 – but as you said, many don’t do this. Maybe Gradle implements its own rules but publishers are probably trying to respect SemVer.

[Drew Hamilton]

Not reading it again right now but I’m referring to https://semver.org/

[mbonnin]

SemVer doesn't know anything about -SNAPSHOT or -dev though 😕

[mbonnin]

If I read correctly, according to SemVer, 3.0.0-dev12 > 3.0.0-alpha01

[louiscad]

#refreshversions does! 😉

[mbonnin]

What algorithm does refreshVersion use?

[louiscad]

Custom

[Javier]

and snapshot > alpha, which shouldnt

[louiscad]

You can see it in the Version.kt file

[louiscad]

@Javier That's debatable

[Javier]

mmm yeah

[Javier]

you have right

[Javier]

indeed snapshot are usually the most recent version

[Javier]

I was wrong because a tricky thing I have to do with reckon

[louiscad]

Only stable supersedes it.

[mbonnin]

Yea, -SNAPSHOT is "another dimmension" I think, it's orthogonal to alpha, dev, rc

[mbonnin]

mmmm 3.0.0-SNAPSHOT > 3.0.0 then?

[mbonnin]

Ah no

[louiscad]

No, that not what I said

[louiscad]

3.0.0 > anything

[mbonnin]

But 3.0.0-SNAPSHOT > 3.0.0-alpha1

[louiscad]

Yes

[Javier]

it is alphabetically

[mbonnin]

Yea, that seems fair

[louiscad]

There's unfortunately no static way to know which of the two is actually the most recent, but I don't depend on snapshots for too long anyway.

[Javier]

znapshot (dont do this XD) > snapshot > rc > milestone

[mbonnin]

And SemVer sorts case-sensitive:

Identifiers with letters or hyphens are compared lexically in ASCII sort order.

So 3.0.0-RC < 3.0.0-alpha1 ?

[mbonnin]

Gosh...

[louiscad]

SemVer is only 2.0.0 though

[louiscad]

I just chose to ignore it personally, going closer to AndroidX versioning inferred conventions instead.

[louiscad]

BTW, are we going to talk about how Kotlin 1.5.1 doesn't exist?

[Javier]

no

[louiscad]

🙃

[Javier]

RC > alpha1

[mbonnin]

@Javier in Gradle world yes but not in SemVer wolrd IIUC

[mbonnin]

upper case chars are less than their equivalent lower case

[mbonnin]

'R' (82) < 'a' (97)

[Javier]

semworld too

[Javier]

are you sure about that?

[Javier]

reckon is very strict with semver, and RC > alpha

[mbonnin]

Well, I'm sure of nothing at this point but the SemVer page says:

ASCII sort order.

[mbonnin]

And "RC" < "alpha" in ascii sort order

[mbonnin]

(writing this in a playground now because I start to doubt everything at this point 😅 )

[louiscad]

Maybe they mean they don't care about éåñīœ

[Javier]

and b?

[louiscad]

Ÿßč ẞßæ Įįí

[mbonnin]

println("RC" < "alpha")
//true

[mbonnin]

At least the spec makes it clear non-alphanum are not allowed:

Identifiers MUST comprise only ASCII alphanumerics and hyphens [0-9A-Za-z-].

[Javier]

but with minus it is higher, that is ugly

[mbonnin]

What do you mean?

[mbonnin]

"-RC" < "-alpha"

[mbonnin]

?

[Javier]

message has been deleted

[Javier]

rc > alpha, but RC < alpha

[mbonnin]

Yep

[Javier]

reckon docs only suggest rc in minus

[mbonnin]

That SemVer document should say case sensitive...

[mbonnin]

reckon docs only suggest rc in minus

Ah, this is why then

[mbonnin]

But then Kotlin and many others use -RC ...

[Javier]

I think I saw in Kotlin projects M1, m1 and milestone1

[Javier]

in RC i dont remember see rc in minus

[Javier]

message has been deleted

[Javier]

there are rc in minus in kotlin versions too

[Javier]

message has been deleted

[Javier]

Gradle is case insensitive no?, if you import RC or rc, it will work

[mbonnin]

That's not 100% clear. https://docs.gradle.org/current/userguide/single_versions.html#version_ordering says the order is case sensitive

[mbonnin]

But also the section about special values like rc uses both rc and RC

[Javier]

but you can't publish rc + RC no?

[mbonnin]

Taht would be a hosting issue I guess?

[mbonnin]

If Sonatype is case sensitive, I don't see any reason why not?

[Javier]

I havent tested it to be honest

[Javier]

but I think the safest way is just all in lowercase

[Javier]

the only different thing is dev one no?

[mbonnin]

Yea, -dev sounds like the big difference

[Javier]

semver alpha < beta < dev , gradle dev < alpha < beta

[Javier]

Why dev is treated different by Gradle?

[mbonnin]

"Historical reasons" ?

[Javier]

Maybe, yeah

[louiscad]

dev is subject to interpretation. When bintray was around, it was my "better snapshots" for reproducible builds. That said, Google used dev before alpha for #compose

[mbonnin]

Yea, I'm guilty of doing the same

[louiscad]

Not sure it matters that much nowadays.

[mbonnin]

Well, we should certainly stop using -dev , right?

[louiscad]

I moved to develop mostly on the main branch and have short lived branches whenever possible, when I need branches, and I semi-automated releasing, so it's less of a concern for me now.

[mbonnin]

So when you want to pin really unstable developer previews, what version do you use?

[louiscad]

One thing though: I'd use dev if conveniently possible the same way I use to, and I'd use 0.x for the #compose like pre-alpha stage.

[louiscad]

If I really needed to, I'd find the timestamps on the snapshot, knowing it's set to go away at some point. At least, it'd make the build reproducible within a given timeframe. Not sure how doable it'd be regarding multi-module publications though, since there's no staging for repos, so I guess the timestamps would be different for every artifact 😅

[Javier]

Personally I just use alpha, beta, and rc . It is enough

[Javier]

and snapshot for publishing every commit on main branch

[Javier]

maybe you can just treat alpha as dev, and if you need one more, you can just add m or milestone

[louiscad]

I publish snapshots manually (via button click, aka. workflow_dispatch). Doing it for every commit would just make climate change worse for no reason.

[Javier]

different strategy, I want to have the snapshot with all commits, similar to what happens in... tivi Chris banes app? or accompanist? I dont remember

[Javier]

for specific commit versions, I just use an alpha

[Javier]

https://github.com/google/accompanist/blob/main/.github/workflows/build.yml, yeah, this one

[mbonnin]

Alphas have a different meaning for me. I'd expect an alpha to be kind of usable, even if it has bugs. -dev are wildy untested and can break completely

[Javier]

I think dev can be snapshots too no?

[mbonnin]

In my specific case not really because I needed builds to be reproducible even if they could break 100%

[louiscad]

Another maven group (e.g. a com.github.xxx project) where you publish dev versions can do.

[louiscad]

Then you use a resolutionStrategy to swap the artifacts.

[mbonnin]

For the record, the GradleVer algorithm is there: https://github.com/gradle/gradle/blob/5ec3f672ed600a86280be490395d70b7bc634862/sub[…]cts/ivyservice/ivyresolve/strategy/StaticVersionComparator.java

[mbonnin]

It's effectively case-insensitive for special values

[Dariusz Kuc]

I'd just follow proper semver so 1.2.3-alpha.0 (in lowercase so you avoid issues with cases sensitive ordering)) -> guess as long as you are consistent then it shouldn't matter

[Dariusz Kuc]

you could even create an action that verifies that suffix is one of -alpha/-beta/-rc or whatever valid values

[mbonnin]

I ultimately went with 3.0.0-alpha01 because of ... "historical reasons" I guess

[mbonnin]

I ended up writing all this before I forget about it: https://github.com/martinbonnin/PragmaVer/tree/main#readme