Versioning

What is the best way to version software?
What system are you using?

Other urls found in this thread:

mozilla.org/en-US/firefox/57.0a1/releasenotes/
twitter.com/AnonBabble

Depends on the software. You really don't want a single number for something like Linux, but using a.b.c.d for some shit that never sees updates is overkill.
Actual answer: Digits of pi. Knuth can't be wrong.

m80

Read again, fag.

`git describe`

unix timestamp is the best way

thats actually really nice, thanks user

YYYYMMDD is the best.

Standard three place semantic versioning. You don't need more than that other than as a fashion statement. The first two are all users of a library need to manage backward/forward compatibility, and the third orders everything else.
Novice programmers often can't get their head around release versions and version control metadata being in two completely different domains and try to glue VCS shit into the release version, although there's a lot less of that happening since subversion died as hashes aren't fashionable.

what if you are retarded and forget to manually update the version and prefer to have a script do it for you so that VCS shit ends up in the version number sometimes?

major.minor.patch-build

I generally use minor just for hotfixes for a patch version.

If your version is automatically updated your version is meaningless. Think of why version numbers exist, why do we need anything more than just a build date or series number? If I'm using your library I need to know if I'm compatible with it, to be able to check what functionality exists, and if specific bugs I don't want to deal with are present. The decision to change your version number is a decision to publish something specific about your software that a user of it needs to know, not simply that it changed.
And if the VCS info ends up in the version you've tied a specific VCS system to the development of your software which makes no fucking sense except in test builds from a CI system not intended for users. Even worse if it's a major component of the version and you wind up stuck using CVS 20 years after it died because migrating to something modern would break your versioning scheme.

extra numbers are bloat and void the unix philosophy

If you don't think much about it yes. But what if you need to release two versions on the same day? And how do you convey that you broke backward compatibility and/or rewrote all from scratch?

Using ISO date like YYYY-MM-DD can look good as a version (notice the minuses for readability) but it's not enough information for the user.

20170921.2, 20170921.3 if there's a third one

I personally think the user doesn't care, so just xx.xx should be enough

Realistically, every release is a breaking release. Bug fixes can break your code. Just start at version 1 and count up. Always upgrade to new versions manually.

No more than this: 1.x.x with alpha/betas at the start of new major versions (2.x.x) with RC releases for possible new major version/stable releases. If the RC proves mostly bug free you go ahead and push the new major version.

I developed this habit when working for a company in the late 90s/early 2000s and have just used it since then.

I use major.minor.patch and then append the "-commits" number to it.
E.g. "1.2.3-4". That way you can signal that there are changes that are neither a new feature nor a bugfix. For example i recently changed the color of a certain widget in my program to make it more readable. That change was too small to warrant a new minor but also wasn't a bugfix. Using the commits you can still communicate that there are changes without cluttering the actual version.

Major releases: I name my releases after pornstars. Start with the really stank ones and gradually move to classier ones. The implied number is their worth/10.

Minor releases: for those I name the releases after scenes or movies they have been at. The number of dudes involved are the implied number of the minor version.

Bugfixes releases: there is never any bugs in my software

What version would Ron Jeremy be?

F.A.G
F = increment it roughly every 45 days so people think the project is alive
A = number of SJWs who appreciated the "improvements" in the software this month
G = number of lines rewritten in Rust

hahaha great post well memed my friend

For libraries semantic versioning is great, but for end-user applications it doesn't really matter I guess. I mean, Firefox is now at version 55, WTF does that even mean?

Personally I would use file or scripting compatibility as the major version in an end-user application. For example, if it's a word processor and the file format changes (even if it is backwards compatible with the old one) I would increment to major number.

You wish it was just a meme...

Oh, don't forget to check out our latest Nightly
mozilla.org/en-US/firefox/57.0a1/releasenotes/

New:
- Firefox Nightly has a new logo (feels good)
- Added an option to the Page Action menu to report a website issue in Firefox Nightly and Firefox Dev Edition (feel free to report all sites with Javascripts and opposing opinions. Not too many used the "Share" button, so we replaced it with "Report" :-) )
- Firefox Nightly now gets updated twice a day so as to help our communities in EMEA and Asia regions to catch regressions and report them during the Americas night. (nice, huh?)

Now can you guess the final version numbers of the stable release which will include these?

the actual release notes:
you got fact checked. nice try trying to fake news me though.

As one of the classiest pornstars out there, he's close to being the final version of a software.
I'm a strong believer of stopping development of a software when it has served it's purpose and not continuously bloating it ad infinitum.

arbitrary versioning:

number of versions that have been incompatible with previous versions
.
major releases
.
critical bugfix patches