5 ms·
I find calendar versioning virtually useless. It reveals the freshness of one's project over much more important information such as maturity, as revealed by se
by plainOldText 7y ago
I find calendar versioning virtually useless. It reveals the freshness of one's project over much more important information such as maturity, as revealed by semantic versioning.
Imagine researching some libraries and having to decide over which one to use, say LibA v2020.01.06 vs LibB 2019.12.31. These versions tell you nothing about the projects except their release dates.
On the other hand, semantic versioning (when not abused) – say LibA v3.0.1 vs LibB 1.0.0 – reveals something useful, such as, that LibA has undergone three major revisions, so perhaps it is much more mature than LibB.
Perhaps the calendar versioning works well with already mature and famous projects – e.g. Ubuntu 18.04, etc – but for smaller projects I don't think it's such a good idea.
Comment v1.0.4-20jan06
- meddlepal 7y agoIt's not a good fit for libraries but it's great for applications. edit: I'm also a huge fan because unlike semver it can be easily generated in a CD pipeline.
- paulddraper 7y agoEverything is a library to someone.
- elsurudo 7y agoNot sure if you should rely on SemVer for maturity estimates either, though. I guess it can be one signal, but I wouldn't say a very useful one.
- itake 7y agowhat would be a more reliable way to know?
- codetrotter 7y agoLook at the following: - Number of commits. - Number of open issues. - Number of closed issues. - How they respond to issues. - Are the commit messages descriptive? - Is the codebase a mess or does it look reasonable?
- deleted 7y ago[deleted]
- LoSboccacc 7y agoyeah is 1.7 a very stable 1.x or a very immature 2.x? what is 0.7 then? and 2.0? can't answer one and the other consistently. it's great for compatibility level, and that's that.
- ppseafield 7y agoIndeed, React got to version 0.14.x before the major number became 15 after a total of three years since the first public release.
- paulddraper 7y agoIf anything, calendar version is superior here because you can tell when it was updated (and if it follows modern conventions, techniques, etc.)
- aidenn0 7y agoHigh major numbers with semver is a "stay far far away" signal for me; each major increment is a non-backwards compatible change.
- pests 7y agoMajor numbers don't always match actual number of major releases. For example Java skipped from 1.4.x to 5.0.0 and React from 0.14.x to 15.0.0.
- Wowfunhappy 7y agoEvery statistic is meaningless insofar as the statistic might be made up.
- eddieh 7y agoAnytime I see calendar versioning I assume one or more of the following are true about the project/package: - it is poorly maintained - the authors are being lazy - it's some kind of unofficial patch or build - marketing has taken over - nostalgia (for Windows 95?) or imitating turn of the century project marketing I don't think there's a good reason to ever deviate from the simple [$MAJOR_CHANGES].[$NEW_FEATURES].[$PATCH]. I don't even think it needs to be formally specified (looking at you SemVer). Simple 3-tuple versioning is almost universally understood. Why fix what isn't broken?
- mhashemi 7y agoA short list of SemVer's failures to communicate project maturity: https://0ver.org/ https://0ver.org/
- Xylakant 7y ago> say LibA v3.0.1 vs LibB 1.0.0 – reveals something useful, such as, that LibA has undergone three major revisions, so perhaps it is much more mature than LibB. It can also mean that LibA messed up their API design twice and had to break BC twice while LibB worked diligently to provide a design that nailed it at first try or spent years in 0.XX territory and only called it stable when they were certain it's stable. I don't consider SemVer useful to compare the maturity of software components. It's not a statement about that. It's useful to get a grip on how hard it's likely to be to go from one version to the next one.