Re:Linux 5.0
by simonh on Monday March 04, 2019 @08:18AM
(#19300971)
How about incrementing the version number by an amount proportional to the lines that have changed in the code base. So 10% of lines have changed and 20% of lines have been added, so increment version number from 5.6 to 7.28.
[ Parent
| on HN ]
Lines of code are even less meaningful than version numbers.
There are some good standards out there for versioning. But honestly the best thing you can do as a developer or sysadmin is to treat every version update like a breaking change and run it through your dev and test environments before pushing to prod.
Re:Linux 5.0
by badsectoracula on Monday March 04, 2019 @09:11AM
(#19301323)
What if you come up with a better algorithm for version 7.28 that is 80% shorter?
One of my favourite Apple history anecdotes:
https://www.folklore.org/StoryView.py?project=Macintosh&stor...
With my tongue firmly still in my cheek, I'd say increment the version number by the difference. So if you deduct 5% of the code and add another 15%, then increment the version number by 20%.
Re:Linux 5.0
by yjftsjthsd-h on Monday March 04, 2019 @09:20AM
(#19301397)
Just use the absolute value. An 80% decrease is a big change just like an 80% increase.
(To be clear: I disagree with the suggestion, I just don't think this is a strong argument against it.)