versioning

[cauerego]

github suggested, and way too traditional, versioning we're using today is actually hard to track.

by all means, let's continue using it because it's so standard...

but i suggest to add more data to it.

examples:

0.2.0 alpha 20210803+2 (had 2 releases)
1.1.4 beta 20211225+7 (7 releases, not counting with alpha)
1.26.2 stable 20220609+43 (could call it stable 43)

i don't care so much for minor updates versus bug fixes. they're basically the same thing to any user.

date of release, however, is much more informative to the future. and names say much more than major version.

but we should probably research about more ideas...

comments? 😁

[kcubeterm]

It's fine to add such data as you suggested.
0.2.0-alpha20210803+2

[cauerego]

i still miss names for significant upgrades, not just major version.

i also think + and - get confusing with numbers that go up and apparently down...

0.2.0_alpha20211223=3#genesis
the first version to work! (hopefully)

0.2.0_beta20220213=4#genesis
the very same version, tested, nothing needed to change, so just promote it to beta... the release number makes a unique release id.

1.2.1_stable20220517=42#genesis
major version gets updated after a big UX overhaul... but functionally everything stays the same, so still same hashtag.

1.3.0_nightly20230319=296#oasis
a minor update on updating meilisearch from 3 to 4 makes everything change how it works. #oasis will bring completely different results from #genesis, but not much changed in the code.

[kcubeterm]

These types of versioning is fine and will be use only on github not with npm as npm support only semver.

[kcubeterm]

Is't sementic versioning standard ? It is simple and look good.

[cauerego]

what do you mean?