I see libs prefixing their `alpha` versions with ` 0 ` but n

Question

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 gt alpha2` in all cases

Javier · Answer

I think the correct semver is `3 3 0 alpha 1`

mbonnin · Answer

Alright no one does that sweat smile

mbonnin · Answer

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 · Answer

yeah it is not usual

Javier · Answer

Thinking on it I use dependabot and or ben manes plugin

Javier · Answer

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 · Answer

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

Javier · Answer

yeah I have a regex too but not for this issue

louiscad · Answer

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 · Answer

< louiscad> hope they fix the browser sorting

Javier · Answer

it is annoying

Drew Hamilton · Answer

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 · Answer

Not reading it again right now but I m referring to <https semver org >

mbonnin · Answer

SemVer doesn t know anything about ` SNAPSHOT` or ` dev` though confused

mbonnin · Answer

If I read correctly according to SemVer `3 0 0 dev12 gt 3 0 0 alpha01`

louiscad · Answer

< CP5659EL9|refreshversions> does wink

mbonnin · Answer

What algorithm does refreshVersion use

louiscad · Answer

Custom

Javier · Answer

and snapshot gt alpha which shouldnt

louiscad · Answer

You can see it in the Version kt file

louiscad · Answer

< Javier> That s debatable

Javier · Answer

mmm yeah

Javier · Answer

you have right

Javier · Answer

indeed snapshot are usually the most recent version

Javier · Answer

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

louiscad · Answer

Only stable supersedes it

mbonnin · Answer

Yea ` SNAPSHOT` is another dimmension I think it s orthogonal to `alpha dev rc`

mbonnin · Answer

mmmm `3 0 0 SNAPSHOT gt 3 0 0` then

mbonnin · Answer

Ah no

louiscad · Answer

No that not what I said

louiscad · Answer

3 0 0 gt anything

mbonnin · Answer

But `3 0 0 SNAPSHOT gt 3 0 0 alpha1`

louiscad · Answer

Yes

Javier · Answer

it is alphabetically

mbonnin · Answer

Yea that seems fair

louiscad · Answer

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 · Answer

znapshot dont do this XD gt snapshot gt rc gt milestone

mbonnin · Answer

And SemVer sorts case sensitive ```Identifiers with letters or hyphens are compared lexically in ASCII sort order ``` So `3 0 0 RC lt 3 0 0 alpha1`

mbonnin · Answer

Gosh

louiscad · Answer

SemVer is only 2 0 0 though

louiscad · Answer

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

louiscad · Answer

BTW are we going to talk about how Kotlin 1 5 1 doesn t exist

Javier · Answer

no

louiscad · Answer

upside down face

Javier · Answer

RC gt alpha1

mbonnin · Answer

< Javier> in Gradle world yes but not in SemVer wolrd IIUC

mbonnin · Answer

upper case chars are less than their equivalent lower case

mbonnin · Answer

R 82 lt a 97

Javier · Answer

semworld too

Javier · Answer

are you sure about that

Javier · Answer

reckon is very strict with semver and RC gt alpha

mbonnin · Answer

Well I m sure of nothing at this point but the SemVer page says ```ASCII sort order ```

mbonnin · Answer

And RC lt alpha in ascii sort order

mbonnin · Answer

writing this in a playground now because I start to doubt everything at this point sweat smile

louiscad · Answer

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

Javier · Answer

and b

louiscad · Answer

Ÿßč ẞßæ Įįí

mbonnin · Answer

```println RC lt alpha true```

mbonnin · Answer

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 · Answer

but with minus it is higher that is ugly

mbonnin · Answer

What do you mean

mbonnin · Answer

``` RC lt alpha ```

Javier · Answer

rc gt alpha but RC lt alpha

mbonnin · Answer

Yep

Javier · Answer

reckon docs only suggest rc in minus

mbonnin · Answer

That SemVer document should say case sensitive

mbonnin · Answer

gt reckon docs only suggest rc in minus Ah this is why then

mbonnin · Answer

But then Kotlin and many others use ` RC`

Javier · Answer

I think I saw in Kotlin projects M1 m1 and milestone1

Javier · Answer

in RC i dont remember see rc in minus

Javier · Answer

there are rc in minus in kotlin versions too

Javier · Answer

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

mbonnin · Answer

That s not 100 clear <https docs gradle org current userguide single versions html version ordering> says the order is case sensitive

mbonnin · Answer

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

Javier · Answer

but you can t publish rc + RC no

mbonnin · Answer

Taht would be a hosting issue I guess

mbonnin · Answer

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

Javier · Answer

I havent tested it to be honest

Javier · Answer

but I think the safest way is just all in lowercase

Javier · Answer

the only different thing is dev one no

mbonnin · Answer

Yea ` dev` sounds like the big difference

Javier · Answer

semver `alpha lt beta lt dev` gradle `dev lt alpha lt beta`

Javier · Answer

Why dev is treated different by Gradle

mbonnin · Answer

Historical reasons

Javier · Answer

Maybe yeah

louiscad · Answer

`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 < CJLTWPH7S|compose>

mbonnin · Answer

Yea I m guilty of doing the same

louiscad · Answer

Not sure it matters that much nowadays

mbonnin · Answer

Well we should certainly stop using ` dev` right

louiscad · Answer

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 · Answer

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

louiscad · Answer

One thing though I d use dev if conveniently possible the same way I use to and I d use 0 x for the < CJLTWPH7S|compose> like pre alpha stage

louiscad · Answer

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 sweat smile

Javier · Answer

Personally I just use `alpha` `beta` and `rc` It is enough

Javier · Answer

and snapshot for publishing every commit on `main` branch

Javier · Answer

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

louiscad · Answer

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 · Answer

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 · Answer

for specific commit versions I just use an alpha

Javier · Answer

<https github com google accompanist blob main github workflows build yml> yeah this one

mbonnin · Answer

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 · Answer

I think dev can be snapshots too no

mbonnin · Answer

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

louiscad · Answer

Another maven group e g a <http com github xxx|com github xxx> project where you publish dev versions can do

louiscad · Answer

Then you use a resolutionStrategy to swap the artifacts

mbonnin · Answer

For the record the GradleVer algorithm is there <https github com gradle gradle blob 5ec3f672ed600a86280be490395d70b7bc634862 subprojects dependency management src main java org gradle api internal artifacts ivyservice ivyresolve strategy StaticVersionComparator java L79|https github com gradle gradle blob 5ec3f672ed600a86280be490395d70b7bc634862 sub cts ivyservice ivyresolve strategy StaticVersionComparator java>

mbonnin · Answer

It s effectively case insensitive for special values

Dariusz Kuc · Answer

I d just follow proper semver so `1 2 3 alpha 0` in lowercase so you avoid issues with cases sensitive ordering gt guess as long as you are consistent then it shouldn t matter

Dariusz Kuc · Answer

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

mbonnin · Answer

I ultimately went with `3 0 0 alpha01` because of historical reasons I guess

mbonnin · Answer

I ended up writing all this before I forget about it <https github com martinbonnin PragmaVer tree main readme>