@nikitonsky how about the metric versioning system?
X.Y.Z
Rules:
- Start at 0.0.0
- Increment Z when you tag a release
- When Z reaches 9, the next version is X.(Y+1).0
- When Y and Z both reach 9, the next version is (X+1).0.0
That's it! Always 10 releases between minor versions and 100 releases between major versions. None of the confusing counting methods of imperial versioning. What could be simpler?
Year and build number. That's what infinite kind uses iirc.
Your metric proposal is bad. I'm sorry, I don't like to say that on a non work discussion. It means there will be huge pressure against doing patch releases from marketing folks. The resulting conversations can be... High energy.
Which is why I boosted the spot-on original post
@nikitonsky Exciting news everyone!
Release 0.0.6853 is out. Upgrade today (or don't).
Or this interpretation
- Enough changes/upgrades that you can justify it being a paid upgrade
- Significant things that should have been included/fixed in the current version, free upgrade
- Changes that 99% of users won't notice
@nikitonsky all my software will be versioned the way it was when i was in university, though
0.0.0.52317

@nikitonsky a git-repo will come soon ^^" https://pridever.org/
also: can I use your image?
UPDATE: git repo: https://github.com/bison--/pridever

@nikitonsky we used to have letters
x.y[l]
x - major new feature(s)
y - minor new feature(s) (or refinement of major(s))
l - fuckups, which unofficially were:
a: again
b: bloody hell
c: crap
d: godt-DAMMIT
f: fucking hell
g: GODT-dammit
h: holy shit this release
i: (unused)
j: just kill me
pretty sure j was as far as we ever got xD
