• nonearther@lemmy.ml
    link
    fedilink
    English
    arrow-up
    32
    ·
    1 year ago

    The only version management I believe in is Nver.

    I write code once and then leave the project completely. Start with 0.0.1 and end with 0.0.1

    • lars@lemmy.world
      link
      fedilink
      arrow-up
      2
      ·
      edit-2
      1 year ago

      Because git doesn’t require, but could definitely benefit from, empty initial commits, my go-to is:

      git init
      git commit -m='🌳 root commit' --allow-empty
      git tag v0.0.0 -am=''
      git add -A
      git commit -m='✨ initial commit'
      git tag v0.0.1 -am=''
      

      which is completely Nver- and Y2K-compliant

  • xmunk@sh.itjust.works
    link
    fedilink
    arrow-up
    12
    ·
    1 year ago

    I support 0ver, my open source project is currently at 0.1.9 - I’m looking forward to releasing 0.1.10 as I continue to avoid the precious 0.2 mark when I become feature complete and open the project up to a wider audience. I assume 0.3 will be a full source rewrite when I achieve Google Scale.

  • It’s funny. With Go modules, though, there’s a very real consequence of moving to 1.0.x; the build system starts imposing different constraints. Same with the move to 2.0.x. Changing versions means more than just throwing a tag in the VCS.

    Most of the time, it’s what you’d do anyway and isn’t a bother. Sometimes - not often, but non-zero - it’s an imposition.

  • gabmus@lemm.ee
    link
    fedilink
    arrow-up
    2
    ·
    1 year ago

    To be completely serious for a moment, conventional commit + what-bump is really useful for doing semver