> > > > general feedback seems to be that users don't care so long as version > > numbers are going up > > Curious to hear more about this. It doesn't match my intuition or > experience running systems but I'm also n=1 and there's a lot of opinions > in the world. > > Leap-frogged by Benedict's response here, but I'm in favor of something > like: > 4.1.0-SNAPSHOT-22Q1 > 4.1.0-SNAPSHOT-22Q2 > ... > > Keeps lexicographical comparison but also embeds the intent of the release > and when it hit all in one bundle. And doesn't blow up our minor #'s and > lead to confusion. >
It's not semantic versioning, and it breaks the code and drivers. The proposal is about publishing a semantic version, providing a structure that is inclusive to the ecosystem and vendors, combined with the limitations/challenges within the project around what version numbers are valid. The SNAPSHOT suffix/label here does not belong to semantic versioning. In maven repositories it gets replaced with timestamps which is "Build metadata" (#spec-item-10) for SemVer. Both suffixing and extending this becomes messy (and again would not be SemVer). Jumping version numbers can happen when releases cut don't pass staging/voting are cast aside and a new release with a new version is cut instead of a "takeX" approach. For the release manager this is a simpler approach (not having to rollback version numbers and changelogs), and for those using development published artefacts (nightlies, staging, etc) (not having versions clobbered). Release manager practices aside, as a user I agree with Brandon, what matters is the version is greater and whether major/minor/patch numbers are greater. I am interested in others PoV, but am seeing this boiling down to a) extending SemVer to these published dev artefacts (which enables and keeps close the ecosystem and vendors), and b) accepting that the code and drivers is fragile with versions and we need to keep it simple.
