Semantic versioning was invented to keep junior developers busy and make PMs feel like they have understanding of the product.

Semantic versioning was invented to keep junior developers busy and make PMs feel like they have understanding of the product. Change my mind.

Die For Epstein's Client List Shirt $21.68

POSIWID: The Purpose Of A System Is What It Does Shirt $21.68

Die For Epstein's Client List Shirt $21.68

  1. 6 days ago
    Anonymous

    The one in the middle was invented by Google (i.e. homosexuals) to make it seem like their product is better because bigger numbers. morons lap it up.

  2. 6 days ago
    Anonymous

    no, semantic versioning was invented to be a versioning scheme that also embeds compatibility information directly into the versioning number. And it does that perfectly. Semver is actually great.

    You're obviously making this thread because you dont understand it, but im feeling generous, so ask away.

    • 6 days ago
      Anonymous

      Why would you make this the end user's problem?

      • 6 days ago
        Anonymous

        we dont?
        the end user isn't supposed to give a shit about semantic versioning

        its for developers

        • 6 days ago
          Anonymous

          If you're distinguishing between "developers" and "end users" then you're clearly on the kool-aid.

          • 6 days ago
            Anonymous

            what a stupid thing to say

          • 6 days ago
            Anonymous

            No, I've been doing this long enough to know that semantic versioning is rarely accurate or useful. You'll learn this in time.

          • 6 days ago
            Anonymous

            sounds like you dont even know what it is

            explain how its "rarely accurate or useful"? its a fricking number that tells you whether its backwards compatible with the previous number.

          • 6 days ago
            Anonymous

            There's no enforcement of correctness. Breaking changes will creep into minor versions, and "big updates" that break nothing will become major versions. Therefore the information is not accurate.

            Almost no one cares about the internal minutiae of your awesome library other than the people maintaining it. They sincerely don't give a frick unless they're forced to share a module ecosystem with it (e.g. Python). Therefore the information is not useful.

            Like I said, you will come to know this in time. The fact that you don't is a problem of your knowledge, not mine.

          • 6 days ago
            Anonymous

            >Breaking changes will creep into minor versions
            and as soon as you realize you fix it and roll out another version

            >and "big updates" that break nothing will become major versions
            no if somebody does this then they're just not following semver correctly

            >Therefore the information is not accurate
            but it is, the above happens very infrequently and is not at all the massive issue you make it out to be. 99% of the time a libraries advertised semver is accurate.

            >Almost no one cares about the internal minutiae of your awesome library
            sure you do when you are managing dependencies. You might be a webshitter who dont do this however.

          • 6 days ago
            Anonymous

            > and as soon as you realize you fix it and roll out another version
            Nope, you tell the users that they use your library wrong.

          • 6 days ago
            Anonymous

            also sounds like you're completely neglecting the advantage of semver
            it truly is amazing that you can just apt-upgrade libA
            and then any application that links with libA automatically gains all the new improvements (up until a breaking change, which is rare) the dev made. Completely without the application developer, or the user, having to do anything. It justwerks^tm.

            > and as soon as you realize you fix it and roll out another version
            Nope, you tell the users that they use your library wrong.

            so sounds like you had a bad experience with a moron lib maintainer over versioning and now you've aimed your hate towards semver rather than that developer.

          • 6 days ago
            Anonymous

            In other words: OP IS A homosexual
            Verification not required.

      • 6 days ago
        Anonymous

        If you're distinguishing between "developers" and "end users" then you're clearly on the kool-aid.

        Real schizo energy in this thread right now.

    • 6 days ago
      Anonymous

      semver is shit,
      it requires a huge investment in time and planning that goes against good software development lifecycles. it also causes useful features to be locked away from your users because backporting is often too hard
      time based point releases with bugfix patch versions and proper deprecation warnings is the best pattern for active software. warn technical users that things will break if they try to upgrade, and enable non technical users to get new features quickly.

      • 6 days ago
        Anonymous

        >semver
        >requires a huge investment in time and planning
        Bro, what lmao

        • 6 days ago
          Anonymous

          >it requires a huge investment in time and planning

          feature A requires changes to library B and C
          C is just a new method that breaks ABI, but B is a public interface rewrite
          now do you stage your changes into 3 releases or do you do it all at once and frick over the devs still supporting your last minor version bump?
          do you continue support for the last minute release and start a new major release series all for this one feature?

          we all know how gnome chooses, but semver has this problem in the trivial case.
          when you build software for a living and have to provide support with a limited team budget, you think about these things and make realistic decisions

          • 6 days ago
            Anonymous

            s/minute/minor
            fricking phone posting I swear

          • 6 days ago
            Anonymous

            >now do you stage your changes into 3 releases or do you do it all at once and frick over the devs still supporting your last minor version bump?
            >do you continue support for the last minute release and start a new major release series all for this one feature?
            What does semantic versioning have to do with any of this?

          • 6 days ago
            Anonymous

            say we have software v1.0
            choice 1 ends in v1.1, v2.0, v2.1 potentially requiring support for all 3 version bumps as well as scheduling those changes
            choice 2 ends in just v2.0 and potentially drops support for 1.0 because it doesn't have change B or C
            the point is semver causes this normal and common scenario to be a huge hassle, and if you have even a small team of devs producing features it quickly becomes an unmanageable tangle of development scheduling and blocker ordering and backport work.
            semver is less useful than a changelog and way more dangerous as it breaks everything the first time you don't follow the rules.

          • 6 days ago
            Anonymous

            anon you have a separate semver for each library

          • 6 days ago
            Anonymous

            >feature A requires changes to library B and C
            ok so im guessing you mean B wants to implement feature A which depends on C implementing a feature to support that first

            >C is just a new method that breaks ABI, but B is a public interface rewrite
            so C increments minor, B increments major. And C now depends on a new major version of B

            >now do you stage your changes into 3 releases
            2 changes you mean? and yes?

            >or do you do it all at once and frick over the devs still supporting your last minor version bump?
            huh?

          • 6 days ago
            Anonymous

            >so I'm guessing
            you guessed wrong but that's okay, you're a semver bandwagoner

            anon you have a separate semver for each library

            splitting a project into different binaries and shared objects is entirely reasonable and semver for every binary is tedious when code is shared this way.

          • 6 days ago
            Anonymous

            >WAAAA ITS TEDIOUS TO PRODUCE GOOD SOFTWARE!!!
            sounds like a you problem

          • 6 days ago
            Anonymous

            it's tedious to do stupid paperwork that has no impact on software quality and just lets useless morons bikeshed the finished product.
            as

            There's no enforcement of correctness. Breaking changes will creep into minor versions, and "big updates" that break nothing will become major versions. Therefore the information is not accurate.

            Almost no one cares about the internal minutiae of your awesome library other than the people maintaining it. They sincerely don't give a frick unless they're forced to share a module ecosystem with it (e.g. Python). Therefore the information is not useful.

            Like I said, you will come to know this in time. The fact that you don't is a problem of your knowledge, not mine.

            correctly notes, lack of any fundamental enforcement means you're always playing the update-and-pray game anyway so what was the point of semver when the changelog and deprecation warnings could far more easily and robustly communicate the information you're trying to encode into a number scheme and hope everybody just gets it.
            it loosely plays well with automated packaging schemes but again, we play the update and pray game each time and have reinvented package locking a hundred times now for a hundred package managers, so what ever was the point?

          • 6 days ago
            Anonymous

            alright keep believing that im tired of trying to convince u guys

          • 6 days ago
            Anonymous

            Don't let the door hit you on the way out.

            I'm sure you or one of your friends will soon be evangelizing the latest software development methodology, or blame-free attributable action framework, or identity-affirming teambuilding exercise for us while we eat the free lunch. We'll nod along and continue to mock you online.

          • 6 days ago
            Anonymous

            all that cope because you cant understand a simple versioning scheme is wild

          • 6 days ago
            Anonymous

            I think I have adequately demonstrated that I've worked with semantic versioning. What you've failed to do is defend it against my critiques.

          • 6 days ago
            Anonymous

            you've fundamentally misunderstood it by the fact that you think you have 3 separate libraries under one project and 1 semver for all of it

          • 6 days ago
            Anonymous

            your only critique is that its "tedious" to simply determine if your commit makes a breaking change or not, which it isn't at all unless you're a complete moron

            I'm OP, not that anon. My critique is that semver is rarely accurate and rarely useful to anyone except the maintainer.

          • 6 days ago
            Anonymous

            >semver is rarely accurate
            it absolutely is, sure mistakes happen where a breaking change doesn't get noticed, but they are rare and get fixed right away with a new version or rollback. 99% of the time the semver is accurate. Its not a common thing to run into at all a library that claims to be compatible via its semver but then isn't.

            >useful to anyone except the maintainer
            its useful to literally fricking anyone using a package manager or anyone manually having to link with any dependencies in their project at all

            I already told you this as well hence why i said i didn't wanna waste more time on you. Thankfully not everyone is as braindead as you and OP and actually semver is the defacto standard versioning scheme by most libraries in the internet. Stay moronic.

          • 6 days ago
            Anonymous

            >most libraries on the internet
            given that most libraries are JavaScript trash, that is not high praise.
            most humans shit out in the open too, are you suggesting that's an admirable behavior?

          • 6 days ago
            Anonymous

            most low level libraries use semver too dumbass

          • 6 days ago
            Anonymous

            you have no evidence to support that assertion and I would know because I work with "low level" libraries in my day job and the versioning schemes are all over the board.

          • 6 days ago
            Anonymous

            ffmpeg, sfml, sdl, boost, openssl, zlib, libcurl, libpng, should i go on?

          • 6 days ago
            Anonymous

            yes please, list every semver low level library for me.

          • 6 days ago
            Anonymous

            >yes please
            im good
            i think i've highlighted your moronation to everyone in the thread already

          • 6 days ago
            Anonymous

            Ubuntu has 85k packages, how many follow your magic semver rules?
            do the ones that respect semver follow the rules strictly?

          • 6 days ago
            Anonymous

            >it absolutely is, sure mistakes happen where a breaking change doesn't get noticed, but they are rare and get fixed right away with a new version or rollback. 99% of the time the semver is accurate. Its not a common thing to run into at all a library that claims to be compatible via its semver but then isn't.
            That's not correct nor is it even sufficient. Every single project that uses semver I've ever seen has had semver violations and every software release is an immutable record in the project's history. Therefore the semver is inaccurate.

            >its useful to literally fricking anyone using a package manager or anyone manually having to link with any dependencies in their project at all
            As others have pointed out, because the semver cannot be trusted, this ends up being a moot point. Projects that depend on the semver library have to release patched incremental builds and test them (and often patch them *again* because of semver violations). Tell me where the value of semver is in this scenario. I am patiently waiting.

            ffmpeg, sfml, sdl, boost, openssl, zlib, libcurl, libpng, should i go on?

            And the truth comes out-- the semver apologists are co-opting good software release practices under the auspice of semver. If you were to believe them, we literally wouldn't have stable library builds without their pet project, when in truth these projects succeed *in spite* of semver. Bunch of fricking leeches.

          • 6 days ago
            Anonymous

            >Projects that depend on the semver library have to release patched incremental builds
            what the frick does this mean

            and yes before you ask, i know what teh frick an incremental build is, i dont think you do, because that statement makes no fricking sense

            >And the truth comes out-- the semver apologists are co-opting good software release practices under the auspice of semver. If you were to believe them, we literally wouldn't have stable library builds without their pet project, when in truth these projects succeed *in spite* of semver. Bunch of fricking leeches.
            i see. You're an actual schizo

          • 6 days ago
            Anonymous

            >what the frick does this mean
            >and yes before you ask, i know what teh frick an incremental build is, i dont think you do, because that statement makes no fricking sense
            Then I guess you'd better critically examine your understanding, because if you're aligned on modern CI/CD practices (which you should be) and you observe reproducible, incremental, immutable software builds (which you also should) then you'd fricking know that a change in your dependency tree generates a release candidate build of your project, at which point you get to find out whether or not the geniuses maintaining your upstream are telling the truth about what they shipped.

            >i see. You're an actual schizo
            I see you've reached the point of name-calling. I guess it was inevitable given how weak your arguments are.

          • 6 days ago
            Anonymous

            what does any of that have to do with semver? If you build your software which depends, and works, on libA v1.0 then thats all you need to care about, and advertise as your dependency. Why are you trying to detect when your project isn't compatible with upstream when they say it is?

            Its not your problem if libA ships v1.1 and it actually isn't compatible anymore with older applications even though it should be, thats their problem.

          • 6 days ago
            Anonymous

            >what does any of that have to do with semver? If you build your software which depends, and works, on libA v1.0 then thats all you need to care about, and advertise as your dependency. Why are you trying to detect when your project isn't compatible with upstream when they say it is?

            Because semver claims to solve this problem, and it doesn't! That's the entire point of this thread!

            I'm trying to keep up to date with the bleeding edge release of libraries because maintaining an up-to-date dependency tree is half the work in keeping a project alive once it's feature-complete. This is an incredibly common problem and I would expect anyone who knows anything about SDLC to recognize it.

            >Its not your problem if libA ships v1.1 and it actually isn't compatible anymore with older applications even though it should be, thats their problem.

            No, it fricking isn't, you stupid frick! It's the problem of whoever holds the broken environment! The maintainer of libA isn't going to step in and fix that shit, some poor sap is going to backport the libraries to hack the software into working. The internet is fricking *full* of these stories.

            Semver is snake oil and just because you enjoy your daily spoonful doesn't mean the rest of us should drink it too. We should think critically about what leads to stable, reproducible software builds and realize that some things people take as gospel contribute _nothing_.

          • 6 days ago
            Anonymous

            What is your alternative? Any other versioning scheme is at BEST equivalent to what semver is at its worst.

            In the worst case scenario where the semver is wrong, the scheme it at least as good as an ordinary versioning scheme where you can only guarantee one specific version is working with your software. Maybe v1.1 isn't backwards compatible with v1.0, however would it be any better if it was v1 and v2 and then you just couldn't tell at fricking all whether it was supposed to be?

            In the best case scenario where the semver isn't wrong, it gives the user the flexibility of using many later versions of the software. This is also the most common case scenario.

            In the worst case its the same as the alternative, its the best case its better.

          • 6 days ago
            Anonymous

            >Any other versioning scheme is at BEST equivalent to what semver is at its worst.
            And this is the snake oil in its undiluted form.

            >What is your alternative?
            Unironically: all software development should be trunk-based unless it produces a frozen artifact, which should be a natural number.

            >but muh compatibility
            As I've repeatedly said ITT, most semver projects end up with permanent errata in their release histories; what actual value is it giving us even in the most myopic, delusional daydream of the semver shills? Frick. All.

            Instead of publishing some bullshit string of numbers, we should publish a symbol map of the interface that can be checked by automation, and this should be attached to every commit on the master branch of a project. This is _far_ more useful for a maintainer of a dependent project (and is almost certainly the direction the industry is moving, if people can ever agree on a standard implementation) because it's _true_. That way, when a library I depend on deprecates a function I need, I get an early warning without having to read some intern or public outreach officer's understanding of what the change means or, much worse, a failed build due to me idiotically placing trust in semver.

          • 6 days ago
            Anonymous

            like with semver you can always just only link with the exact advertised dependency version of your software as if it didn't use semver at all.

          • 6 days ago
            Anonymous

            >I'm trying to keep up to date with the bleeding edge release of libraries because maintaining an up-to-date dependency tree is half the work in keeping a project alive once it's feature-complete
            ArchBlack person detected. People who release actual software take the latest compatible version available at the time they start the project, then release it, then maybe work on bumping the dependency versions later if the security team complains. Semver is the by far best way to check if your upgrade would break something. It’s not perfect but it’s sure as frick better than whatever you’re thinking of

          • 6 days ago
            Anonymous

            Incorrect on all takes, my young friend. Not only do I not run Arch, but I also have worked on numerous projects that evolve side by side with provider libraries rather than being conceived on a whiteboard using some mature, stable ecosystem, and I proposed something that _you can't even understand_ that is better than semver because, as I stated, it doesn't lie to the user.

            Just accept it. You're out of your element on this. Whatever little passion project you've thrown a couple commits to is not a defense of a shitty paradigm like semver, it is a sad bleat of protest against change.

          • 6 days ago
            Anonymous

            your only critique is that its "tedious" to simply determine if your commit makes a breaking change or not, which it isn't at all unless you're a complete moron

      • 6 days ago
        Anonymous

        >it requires a huge investment in time and planning

    • 6 days ago
      Anonymous

      The people who use it, but don't follow the rules, are the biggest scum on earth. For example, introducing breaking changes in a minor version. Or rust developers who are too scared to upgrade a major version, and stay at 0.1.infinity

  3. 6 days ago
    Anonymous

    Semantics is based, but only with 2 numbers

  4. 6 days ago
    Anonymous

    For me it's YYYY.MM.DD.rev

    • 6 days ago
      Anonymous

      Dunno.
      If semver was enforced (by language tooling or whatever else), it would be great.
      But without enforcement you always have to perform the ritual of let-me-upgrade-and-see-what-breaks.
      I don't see a better alternative to semver, esp in case you need to maintain two major versions of a certain API at the same time. Having "v3.23.whatever" and "v2.65.whatever" looks ok. Not as straightforward to do if you follow e.g. pattern.

      • 6 days ago
        Anonymous

        >esp in case you need to maintain two major versions of a certain API at the same time
        Yucky stinky poopy yucky stinky poopy pukey pukey stinky yucky poopy.

  5. 6 days ago
    Anonymous

    >software that has been developed since 2014
    >widely used
    >v0.8

  6. 6 days ago
    Anonymous

    >phoneposter has dogshit opinion
    Sasuga IQfy!

  7. 6 days ago
    Anonymous

    >terminally online troon doesn't know how to handle reality
    say it ain't so

    • 6 days ago
      Anonymous

      who are you quoting? yourself? that's not exactly constructive conversation on IQfy, you know.

  8. 6 days ago
    Anonymous

    no that's accurate. I'm busy and I do not have the time to hold every Junior's hand because they can't figure out how to fill their hours with billable work.

  9. 6 days ago
    Anonymous

    >current
    >backup_1,backup_2,...backup_87 for previous versions

  10. 6 days ago
    Anonymous

    >RC1
    >RC2

Your email address will not be published. Required fields are marked *