Gregory's ServerI propose we replace semantic versioning with pride versioning
 139 comments
   @j_j the proud version also jumps up to a large round number significantly different from the previous one when the marketing team gets involved, even if there's nothing to be proud of.  @nikitonsky    @wolf480pl @martin_ueding @nikitonsky the sort of pride that comes before a fall...  @martin_ueding @nikitonsky With those in mind I'd like to propose shifting the semantics. From last to first:  @jelte @martin_ueding @nikitonsky this is just reframing semantic versioning in pride-shame language, and I love it  @c0dec0dec0de @jelte @martin_ueding @nikitonsky I had been thinking shame/pride/shame. Major shame is when you knowingly break something, patch shame is when you had unknowingly broken something. I once had a team at work will into triple-digit major versions. They sometimes broke compatibility several times a day. It was a struggle to convince them how much of an issue that was, and how no amount of monorepo was going to make people happy with them. @jbqueru @jelte @martin_ueding @nikitonsky we have static versions because we hate ourselves, I guess  @jbqueru @c0dec0dec0de @jelte @martin_ueding @nikitonsky I'm proud when my software doesn't need new features anymore (therefore it's finished) and only requires some maintainence once a year or so. so shame/shame/normal for me @cybertailor is like to make the suggest making the bugfix/patch level in semver humility @jbqueru @c0dec0dec0de @jelte @nikitonsky @martin_ueding @jbqueru @jelte @nikitonsky this can break down a little at runtime if you’re deploying components in a distributed manner - but you can always embed the VCS reference as a proxy for version in that case. @c0dec0dec0de @jbqueru @jelte @nikitonsky @martin_ueding @jbqueru @jelte @nikitonsky sorry, work with people in a monopod with absolutely no tracking and they just smack themselves in the forehead regularly and go “oh no, these two components were built from different code and couldn’t figure it out because they talk in our unversioned binary interface language! Better not change anything about our process.”  @jelte @martin_ueding @nikitonsky Well, I had to edit it a little bit to make the text fit better, but I like this version (hehe) better.    @JessTheUnstill @nikitonsky  @Raccoon   @hazelnot @nikitonsky I honestly have no idea how versioning works and just assumed this is how it works lmfao     @nikitonsky And compatible versioning with eaks versioning:  @nikitonsky how about the metric versioning system? X.Y.Z Rules: 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  @aburka @nikitonsky Nah, most system work on the assumption that a major version is incompatible. So while it's more or less safe to update to latest minor and patch, major version upgrades don't happen that often.    @jsled @TyrionTargaryen @nikitonsky Heh, came here to mention the 4th digit, sometimes extra shame, often 'effort to create shame' (build numbers) 👀   @nikitonsky     I worked for a software company in the 90s/around the millennium that shipped "point" releases, not "patch" releases, because the word "patch" connotes a problem. @nikitonsky insta-coding this into my current project's version class. i'll use this post as a credit url until you get a better one ;-)  @nikitonsky@mastodon.online Oh, that's why all my projects are still 0 as the first segment!  Or this interpretation - Enough changes/upgrades that you can justify it being a paid upgrade   @owiecc @nikitonsky … or the 2nd version of the 5th really-final-I-mean-it-this-time pre v1 release?  @nikitonsky "My faith! For more than forty years I have been speaking prose while knowing nothing of it, and I am the most obliged person in the world to you for telling me so."   @nikitonsky all my software will be versioned the way it was when i was in university, though 0.0.0.52317      @nikitonsky The version number should be a single integer that gets bumped by one on every change :abloblamp:   @nikitonsky With the invisible fourth number, the "this was so embarrassing you need to diff the code to discover the fix" element. Also useful for fixing typos in comments.  @nikitonsky a git-repo will come soon ^^" https://pridever.org/ UPDATE: git repo: https://github.com/bison--/pridever @cybertailor @nikitonsky did, the page is still temporary / just to have something for today ^^   @nikitonsky now that is the kind of definition of pride we need to use and support. Very nice.   @nikitonsky Semantic versioning is essential for libraries exposing APIs. But apps can use any versioning and this is what usually happens anyway.   @nikitonsky nah automatically generate the version number based on total commits since the last build,    @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 pretty sure j was as far as we ever got xD  @nikitonsky 2.7.123b - where the "b" means "please forget the previous release ever happened and pretend this is the one i gave you instead"      @SteveClough @nikitonsky 0.3.83625 would be a typical number for me in this system.   @nikitonsky@mastodon.online Almost what I did for AAAAXY. Except that I also bump the last number for mere changes to upstream dependencies that should not impact anything.  @nikitonsky for libraries, : "Proud version" with lot of breaking changes :blobsob:  @nikitonsky It occurs to me that depending on your feelings about backwards compatibility it could actually be SHAME.pride.shame   @vwbusguy @nikitonsky I mean seriously. This is how Linux kernel versioning works, isn't it?   @stylus Another reason we get more frequent major version bumps on the kernel nowadays is that 2.* lasted so long that many tools became dependent on checking for majorver == 2. When 3.* first came out we had to internally patch 3.x to 2.6.4x for a few months to keep things working until everything could be fixed. Lessons were learned..  @nikitonsky How about “don’t ask, don’t tell” versions, the ones where you count up internally but don’t go public?   @nikitonsky@mastodon.online This is literally how my company does product versioning lmao    I think this would be the most humane way to version software. You might ask, yeah but what about API's and contracts? My very strange opinion on this is that, if project developers empathize with people using and operating their software, the API contract problem is solved and won't have to be reflected in the version number.
 @nikitonsky counter proposition for x.y.z: X: i'll break all the things you're used to (and I don't give a shit)   @nikitonsky left my current company two years ago, and was convinced to come back last month. I came back to the last revision I released being the gold standard despite the big number going up four times.  @nikitonsky I see *some* issues arising from negative version numbers... :neocat_think: ::P  2. - the number of rewrites  @nikitonsky I only feel shame because I can never drive an idea into the state that it needs versioning…  @nikitonsky@mastodon.onlineGet a $750 Roblox Gift Card!   @nikitonsky At first I thought it was a proposal for a versioning system for your gender identity.  @nikitonsky Or mathematical constant reasoning. LaTeX versions are just asymptotically approach the game of π; the current version of LaTeX is 3.141592653. Likewise, Metafont versions approach e, with the current version being 2.7182818. I have adopted this idiosyncratic version numbering system for a number of non serious projects mainly for my own amusement.     @nikitonsky can we have both? v<pride version >-<semantic version>-<final/pink_promise_final/>-<(optional) curse>   @nikitonsky Versioning is for idiots. Just write it bug free in the first place. Then stop adding pointless features.    @nikitonsky This is the most comprehensive non-IT explanation for semantic versioning if I ever saw one.  @nikitonsky I wonder what this says about PuTTY. 😄 It's been around for 25 years, gets regular updates, and is currently at 0.82 (updated last month). I always assumed Simon was trolling the conventional semantic system in his own way. @nikitonsky  @nikitonsky The problem here is anything I make will be 1.0.7439 because I hate my projects after 1.0...    @nikitonsky Semantic version can just drop the major number. If you ever increment that you've actually created a fork.  The most scrupulous devs will be on 0.0.100, and the most prideful being on version 100.0.0 - perhaps both with comparable quality to their products. 😆   @nikitonsky not joking: this has been my strategy since i started making programs.  @nikitonsky Вже давно знайшов, ось вирішив теж поділитися https://semver.org/lang/uk/  @nikitonsky Remember that the proud version needs a special release date, too! I am having one tomorrow.  Nutshell history of software version numbering format: a.b.c.d a : major/proud release (Note that Windows 3.11 was released before a second decimal point had been invented.)  |
@nikitonsky love it, is this post the canonical URL for quoting? :)