[HN Gopher] What's in a version number? (Or: Musings on backward...
       ___________________________________________________________________
        
       What's in a version number? (Or: Musings on backwards
       compatibility)
        
       Author : genericlemon24
       Score  : 15 points
       Date   : 2021-10-07 12:05 UTC (1 days ago)
        
 (HTM) web link (alexgaynor.net)
 (TXT) w3m dump (alexgaynor.net)
        
       | ghoward wrote:
       | I like his idea, but it sounds a little hypocritical coming from
       | someone who advocated a change that broke _many_ distros builds
       | of the Python cryptography package.
       | 
       | Personally, I think he spent his "backwards-incompatibility
       | budget" for about 5 _years_ with that change because that 's
       | probably how long it will take for the new version of
       | cryptography to be widely adopted and supported long-term.
        
       | itamarst wrote:
       | If you accept this argument, the next logical step is figuring
       | out what features are being used and how. Standard method is just
       | guessing, but there's:
       | 
       | 1. What rustc does with crater (linked from article), where you
       | can actually test real code. On a smaller scale, the author of
       | the article points out cryptography package for Python, which
       | runs tests of its most popular upstream dependencies. This latter
       | is probably feasible for many libraries.
       | 
       | 2. Analytics, though this requires work to make it private and
       | anonymous, and for libraries maybe requires system-level
       | infrastructure. (Again, this was suggested by Alex.)
       | 
       | 3. Beta testing, surveys, and other forms of user feedback.
        
       | nammi wrote:
       | I was really surprised Rich Hickey's talk wasn't linked to:
       | https://youtu.be/oyLBGkS5ICk
        
       | yawnxyz wrote:
       | I work with a bunch of biologists and one of my jobs is to find a
       | solution for the filename_final_final_FINALNEWEST.xlsx problem...
       | thinking about how to convince people to use something like a
       | versioning system, or just use a single number, e.g.
       | filename-4.xlsx, and write a tool to collapse all those finals
       | into a number, e.g. filename_final_final.xlsx into
       | filename_final2.xlsx...
       | 
       | I'm still not sure if it's the best way to go about it though.
       | But I think version numbering is still much stronger than tacking
       | multiple "finals" to a file name. Happy to hear what others are
       | doing!
        
         | vegetablepotpie wrote:
         | The method I use and often encourage other people to use is
         | version control latex and csv files and python scripts in git,
         | which can do everything MS office does. This has worked exactly
         | zero times, so what I encourage others to do instead is...
         | 
         | Use the format filename_YEAR_MO_DY_username.xlsx. This has the
         | benefit that Lexicographic ordering every OS does in its file
         | explorer is the same as chronological order, so it acts as a
         | crude version control system.
        
           | xapata wrote:
           | I add a letter to distinguish between updates made on the
           | same day: 2021-10-08a, 2021-10-08b. So far no one has been so
           | quick with updates that I've gone past z, but I'll have my
           | y2k moment someday.
        
           | intrepidhero wrote:
           | > The method I use and often encourage other people to use is
           | version control latex and csv files and python scripts in
           | git, which can do everything MS office does. This has worked
           | exactly zero times
           | 
           | Yeah and, sadly, yeah. Someday.
        
         | intrepidhero wrote:
         | Been fighting the same fight. Anytime someone sends me a file
         | with a with _FINAL_XYZ_approved_modified_etc I delete all that
         | stuff and increment the version number before I send it back to
         | them. Folks eventually catch on. It helps that I'm the one
         | writing procedures for the document management people to
         | follow. One surprising (to me) argument against was that people
         | don't like it when the first version we produce (meaning our
         | group throws it over the wall to another group) is higher than
         | version 0. I shrug and say, it's just a number.
         | 
         | Sure there's lots of more robust ways to track versions. But
         | the above simple convention is a step function in quality of
         | life while requiring hardly any work.
        
           | jasonpeacock wrote:
           | I've run into that too. People attach a lot of value to
           | version numbers, even for internal projects/releases, and
           | it's hard to get their perspective shifted to just accept it
           | as communication tool (e.g. semver).
           | 
           | There's nothing special about 1.0.0 vs 2.0.0, it just means
           | there was a breaking change and you may need to do some work
           | when upgrading.
           | 
           | And a major, awesome feature might get released as 1.15.25 ->
           | 1.16.0, that's OK. (marketing hates this)
        
       ___________________________________________________________________
       (page generated 2021-10-08 23:01 UTC)