3 ms·

I never found stric following of semantic versioning to be a good fit for product versions. It makes sense only for libraries and packages.

paulryanrogers 8y ago
Why not?
- insulanian 8y ago
  Because a backward incompatible change can be required to implement a small feature or even fix a bug, which does not justify major version bump from the production life cycle perspective.
  - insulanian 8y ago
    Also, major new feature, even though it is backward compatible, is a better reason for major version number increase.
    - paulryanrogers 8y ago
      In Semver the second part communicates features, not 'major'. So magnitude of the features should not matter. Unless version is more for marketing than communicating the precise nature of the changes.
      - insulanian 8y ago
        That's why I'm saying semver is not a good fit for product versions. It's too technical and doesn't fit well with PR, marketing and product management.
        paulryanrogers 8y ago
        Point taken. I'm curious if using the second/feature part of SemVer for the advertised product version would be a workable compromise? Or must marketing always get "top billing" in that precious left-most spot?
  - paulryanrogers 8y ago
    What about the "production life cycle perspective" requires that major version numbers not bump in those cases? If version pattern is thought of as "compatibility.feature.fix" then there is no reason that feature and fix changes cannot also bump the right most number [as compatibility is broken]. EDIT: for clarity
    - insulanian 8y ago
      > What about the "production life cycle perspective" requires that major version numbers not bump in those cases? Let's say you just finished a big campaign, promoting the new major version of the software (e.g. 2.0) to customers. After starting with rollout, couple of weeks down the line shit happens (it does happen) and you realise you have a bug, which you can only fix by introducing backward incompatibility and providing e.g. a migration tool to apply the fix and migrate data. Now according to semver you would have to release version 3.0 with basically one change, which is something that product management will not accept (and rightly so), because next big release and marketing campaign would have to be for version 4.0, and customers will ask "what the heck happened with version 3.0". Long story short, semver is "too automatic" to fit in product management, but it is a good fit for package managers and libraries where this is less obvious to the end user.
      - paulryanrogers 8y ago
        > Let's say you just finished a big campaign, promoting the new major version... Again, this sounds like a marketing concern. A software or service need not be marketed by the technical version. As mentioned elsewhere Java famously promotes it's dot version and is famously maintains backwards compatibility to v1.0, IIRC. Consider that a business consuming software and services is not only concerned with the market version/edition but their IT very much cares about the technical version and what each release communicates. Windows has an internal version number besides the ME, XP, Vista bullshit.
    - insulanian 8y ago
      > If version pattern is thought of as "compatibility.feature.fix" then there is no reason that feature and fix changes cannot also bump the right most number [as compatibility is broken]. We think about it as "product(Management)Version.developmentIteration.emergencyPatch". First number is incremented only in coordination with business/PR/marketing. Second number is incremented after every development iteration (mostly one, but sometimes multiple sprints), regardless of new features being introduced or just code stabilisation is being worked on, and regardless of it being backward compatible or not. As someone mentioned, release notes are there to communicate that part. Third number is incremented only if we're fixing some emergency issue on one of the release branches. E.g. customer running version 4.2, reports a bug. We fix it on the branch and release 4.2.1
- snowwindwaves 8y ago
  Marketing

paulryanrogers 8y ago

Why not?

insulanian 8y ago
Because a backward incompatible change can be required to implement a small feature or even fix a bug, which does not justify major version bump from the production life cycle perspective.
- insulanian 8y ago
  Also, major new feature, even though it is backward compatible, is a better reason for major version number increase.
  - paulryanrogers 8y ago
    In Semver the second part communicates features, not 'major'. So magnitude of the features should not matter. Unless version is more for marketing than communicating the precise nature of the changes.
    - insulanian 8y ago
      That's why I'm saying semver is not a good fit for product versions. It's too technical and doesn't fit well with PR, marketing and product management.
      - paulryanrogers 8y ago
        Point taken. I'm curious if using the second/feature part of SemVer for the advertised product version would be a workable compromise? Or must marketing always get "top billing" in that precious left-most spot?
- paulryanrogers 8y ago
  What about the "production life cycle perspective" requires that major version numbers not bump in those cases? If version pattern is thought of as "compatibility.feature.fix" then there is no reason that feature and fix changes cannot also bump the right most number [as compatibility is broken]. EDIT: for clarity
  - insulanian 8y ago
    > What about the "production life cycle perspective" requires that major version numbers not bump in those cases? Let's say you just finished a big campaign, promoting the new major version of the software (e.g. 2.0) to customers. After starting with rollout, couple of weeks down the line shit happens (it does happen) and you realise you have a bug, which you can only fix by introducing backward incompatibility and providing e.g. a migration tool to apply the fix and migrate data. Now according to semver you would have to release version 3.0 with basically one change, which is something that product management will not accept (and rightly so), because next big release and marketing campaign would have to be for version 4.0, and customers will ask "what the heck happened with version 3.0". Long story short, semver is "too automatic" to fit in product management, but it is a good fit for package managers and libraries where this is less obvious to the end user.
    - paulryanrogers 8y ago
      > Let's say you just finished a big campaign, promoting the new major version... Again, this sounds like a marketing concern. A software or service need not be marketed by the technical version. As mentioned elsewhere Java famously promotes it's dot version and is famously maintains backwards compatibility to v1.0, IIRC. Consider that a business consuming software and services is not only concerned with the market version/edition but their IT very much cares about the technical version and what each release communicates. Windows has an internal version number besides the ME, XP, Vista bullshit.
  - insulanian 8y ago
    > If version pattern is thought of as "compatibility.feature.fix" then there is no reason that feature and fix changes cannot also bump the right most number [as compatibility is broken]. We think about it as "product(Management)Version.developmentIteration.emergencyPatch". First number is incremented only in coordination with business/PR/marketing. Second number is incremented after every development iteration (mostly one, but sometimes multiple sprints), regardless of new features being introduced or just code stabilisation is being worked on, and regardless of it being backward compatible or not. As someone mentioned, release notes are there to communicate that part. Third number is incremented only if we're fixing some emergency issue on one of the release branches. E.g. customer running version 4.2, reports a bug. We fix it on the branch and release 4.2.1
snowwindwaves 8y ago
Marketing