Programmer Humor @lemmy.ml ☆ Yσɠƚԋσʂ ☆ @lemmy.ml 5 days ago

Pride Versioning

35 comments

I prefer for versioning to have no discernible pattern
This is is basically just true
- I wish it was true here. Major releases are always the most shameful ones because so much is always left to "we can fix that later"
  
  Hey as long as it ships it can always be an RMA. If there's a problem the customer will let us know™
- So pride is a synonym for semantic. Got it.
The fairly mature internal component we're working on is v0.0.134.
- A shameful display!
- For an internal project that's fine, and under semantic versioning you can basically break anything you like before v1.0.0 so it's probably valid
https://0ver.org/zerover_0_based_versioning.html
- I'm afraid most, if not all, of the projects listed use pride versioning, also.
- I've noticed this and seeing it all laid out is hilarious. (So, so many JS frameworks omg)
  
  Is this basically so they can forever say: "Well don't expect it to be feature complete, it's not even 1.0 yet!" ??
  
  I don't think, it's as conscious of a decision. Projects above a certain level of complexity will just never realistically reach the criteria one might associate with a 1.0 (stable API, no known bugs, largely feature-complete). And then especially non-commercial projects just don't have an incentive to arbitrarily proclaim that they fulfill these criteria...
- This is hilarious
I once had someone open an issue in my side project repo who asked about a major release bump and whether it meant there were any breaking changes or major changes and I was just like idk I just thought I added enough and felt like bumping the major version ¯⁠\⁠_⁠(⁠ツ⁠)⁠_⁠/⁠¯
- I think is the logic used for Linux kernel versioning so you're in good company.
  
  But everyone should really follow semantic versioning. It makes life so much easier.
  
  either have meaning to the number and do semantic versioning, or don't bother and simply use dates or maybe simple increments
when the release notes just says "bug fixes"
- "Various improvements"
  
  "We are always hard at work making your experience better!"
  This release note has of course been the same for the last 3 years
I use CalVer in my projects. I might transition to SemVer some time, but given that most of my projects are standalone, it doesn't make much sense to track external compatibility.

Pride Versioning makes no sense, because In never quite proud enough of my work to distinguish it from 0ver.
- Just add a leading "0."
  
  Edit: TIL 0ver
I read this as pride as in
- Pride versioning:
  
  LG
  
  LGB
  
  LGBT
  
  LGBTQ
  
  LGBTQI
  
  LGBTQIA
  
  LGBTQIA+
  
  The + is just standing for latest
  
  Is + when they stop counting versions and just use a SaaS model?
I really had to fight for versioning. Everyone was just patch version here. Breaking changes in the API, new features, completely overhauled design? Well, it's 0.6.24 instead of 0.6.23 now.

But gladly we're moving away from version numbers alltogether. Starting next year it will be 2025.1.0 with monthly releases
- Release please with conventional commit PR titles.
That reminds me, maybe I should re-watch Doug Hickey’s full-throated attack on versioning & breaking changes. Spec-ulation Keynote
- a classic
Thought it's 2.7.1828182845904523536 for a sec

You've viewed 35 comments.