[HN Gopher] Major Version Numbers Are Not Sacred
       ___________________________________________________________________
        
       Major Version Numbers Are Not Sacred
        
       Author : mojombo
       Score  : 14 points
       Date   : 2022-05-23 19:15 UTC (3 hours ago)
        
 (HTM) web link (tom.preston-werner.com)
 (TXT) w3m dump (tom.preston-werner.com)
        
       | mc4ndr3 wrote:
       | Semver is best treated as a defensive strategy: I choose to
       | follow semver principles for the packages that I upload, but I
       | never trust other packages to reliably follow semver.
       | 
       | For this reason, I often pin not just the major, but also the
       | minor and patch version of a dependency in my package
       | configurations. And also cache the artifacts (go mod vendor,
       | private package registry, etc.) So that any breaking changes are
       | easy to identify and triage in the development process before
       | surprising production.
       | 
       | If you do pin only at major level, then try to target a Long Term
       | Support (LTS) series. Because LTS releases are much more likely
       | to receive active maintenance, security updates, and stable, non-
       | breaking changes, compared to non-LTS releases.
       | 
       | Regular, automated testing will help to identify more breaking
       | changes before deploying production changes.
       | 
       | In the worst case, a breaking dependency change occurs
       | contemporary with a first party bug. You need to be able to
       | quickly identify, isolate, reset the third party version to a
       | safe, compatible version in a small, fast hotfix while also
       | working on fixing the first party bug.
       | 
       | Don't be like those lazy dev teams that don't pin even the
       | _major_ version of their components. Remember, operating systems
       | and programming languages can introduce breaking changes. Your
       | Docker base image should already offer at least major version
       | tags, so make use of them.
       | 
       | Some will prefer to strike a balance between specificity and
       | flexibility, for example omitting the build version, patch
       | version, and/or minor version. That's a reasonable approach, too.
       | But that approach has some implications regarding production
       | deployments, which one prefers not to accidentally update
       | production. A breaking change can even arrive in scant seconds
       | between pre-production testing and production release. So if you
       | do choose to pin at major level, then make sure to deploy exactly
       | the same, pre-tested, whole project artifact to production.
       | Don't, for example, rebuild a Docker image to production that
       | targets insufficiently granular component versions.
       | 
       | Regardless of the versioning approach, I would not recommend
       | doing it one way for pre-production environments and a different
       | way for production environments.
       | 
       | Any divergence in packaging will make troubleshooting
       | unnecessarily complicated, and you won't truly have tested the
       | production code anyway. Don't try to pin full in production while
       | pinning at a diffferent granularity in non-production
       | environments. Do reuse the same package configuration throughout
       | the pipeline, with changes going the normal forward path all the
       | way from local development to testing to production.
       | 
       | The problem is not so much that breaking changes are occurring
       | all the time. There's the psychological aspect that we neglect to
       | plan for long term bitrot. For example, the app the began as a
       | slapdash hackathon project, is now in production and several
       | months (or years) have passed. Well, in that timeframe the
       | probability of a breaking change has dramatically increased. You
       | may not even be able to build the project again, due to breaking
       | changes. Pinning in both documentation and package configuration
       | is a way to future-proof your project, so that you will have the
       | important details ready when you need them.
       | 
       | Treat your projects like a science experiment in a timecapsule.
       | So that you can reliably rebuild and redeploy, later, when
       | suddenly the landscape has dramatically shifted.
        
       ___________________________________________________________________
       (page generated 2022-05-23 23:01 UTC)