• PieMePlenty@lemmy.world
    link
    fedilink
    arrow-up
    14
    arrow-down
    1
    ·
    edit-2
    6 小时前

    I recently realized: fuck it, just have the build date as the version: 2026.02.28.14 with the last number being the hour. I can immediately tell when something is on latest or not. You can get a little cheeky with the short year ‘26’ but that’s it. No reason to have some arbitrary numbers represent some strange philosophy behind them.

    • grrgyle@slrpnk.net
      link
      fedilink
      arrow-up
      1
      ·
      2 小时前

      I like using the short hash from the latest git commit used to build, to avoid confusion among multiple devs on parallel streams

    • the_wonderfool@piefed.social
      link
      fedilink
      English
      arrow-up
      14
      ·
      5 小时前

      Tried it in the past but ultimately abandoned it, as then release numbers lost all added meaning. I can remember what happened in release 2.0.0 or (kinda) 3.5.0, but what the hell was release 2025.02.15? Why did it break this random function?

    • ilinamorato@lemmy.world
      link
      fedilink
      arrow-up
      12
      ·
      6 小时前

      Can you immediately tell? Do you memorize the last day you released? Do you release daily? There’s definitely some benefit to making the version equal to the date, but you lose all the other benefits of semver (categorizing the scope of the release being the big one). That’s not a strange philosophy, it’s just being a good api provider.

      • PieMePlenty@lemmy.world
        link
        fedilink
        arrow-up
        4
        ·
        5 小时前

        You’re right. I’m looking at it through a very limited scope: nightly releases. I’ve been working with “latest” so long, I forgot actual versions exist.

    • qarbone@lemmy.world
      link
      fedilink
      English
      arrow-up
      1
      arrow-down
      2
      ·
      3 小时前

      The philosophy is pretty straight-forward. I don’t know why the world is pretending it’s difficult.