Only DEVELOPERS and Engineers will answer this correctly

This thread is for professionals only - amateurs need not apply.

Other urls found in this thread:

semver.org/
twitter.com/NSFWRedditVideo

1.9.0

2.0.01

1.9.1

1.10
1.11
1.12
2.1

1.9a

1.9.01

1.10

I win. stupid loosers

3 because there were some compatibility errors with the number 2

1.9.4.91b
We had some issues with the other three.

1.0
1.1
1.2
1.3
1.4
1.5
1.6
1.7
1.8
1.9
1.A
1.B
1.C
1.D
1.E
1.F

1.shotofblack

5.x
Welcome to elasticsearch

>1.10
17.0, because big leaps in version number make it look like we're progressing
Also using the current year looks more idiomatic to laymen

1.10

2.10

1.10

Bryzen

I wish devs did this.

TOSSUG Baby Fish

y u no semver?

Huge changes and improvements: 2.0
Small changes and improvements: 1.10
Bugs fixes and some tweaks: 1.9.1
Amirite?

95

10.0

I'm not a programmer, can someone explain the deal with 2

DELUXE Pro Edition

you mean golang?

Minecraft beta

i think he was poking at how microsoft skipped windows 9 because of compatibility issues and just used 10

What incompatibility will happen if you used 2.0 for version numbers?

no, i think it was a joke

1.A

1.10, Don't change the major version unless major update or re-work.
It goes majorVersion.majorRevision.minorVersion.minorRevision

>his version numbers don't asymptotically approach pi as they progress

1.9b

>not using year.month

II
Apple style

Don't. Americans can't read Roman numerals.

almost like WoW

>tying your releases to calendar

name a single downside

Long release names.
No indicator of massive/breaking changes.

1.7
1.8
1.9
1.9RC1a
1.9RC1b (release)
1.9RC2
2.1 developer preview
2.1 beta
3.0
3.5.6
10

>Long release names.
17.8.4 is long?
>No indicator of massive/breaking changes.
Like you pay attention to that shit anyway.

>single digit days and months
>two digit years
Please user, don't be stupid.

Only correct answer is 10... Windows 10.

2017.08.04
wow I doubled the length and I still don't care

1.9bis

Use the ISO8601 format: 2017-08-04.
Sure, it works as a format, but it really doesn't contain any real meaning.
Maybe if you have a very consistent release schedule, using the date may be more appropriate, and you may drop the day or something.

1.01
1.02
1.03
1.04
2.03
2.10
2.11
3.0
3.1
NT 3.1
for Workgroups 3.11
3.2
NT 3.5
NT 3.51
95
NT 4.0
98
2000
ME
XP
Vista
7
8
8.1
10
10 Creator's Update

1.9.1.1.1.1.1

>but it really doesn't contain any real meaning.
Neither does any other format.
>BUT MUH MAJOR CHANGES
Utterly irrelevant to the end user; all they care about is which version is best, whether that's 5.9.2 or cat.dog.rhino

>2000
>ME
aren't these the same thing?

also
>10
>10 Creator's Update
where is the Anniversary Update?

You seem to have mixed up release names with release versions.

1.A

>pay attention to that shit anyway
I don't need to as portage does that for me automatically. Having
=foo/bar-1.2* ~amd64
in package.keywords for example means that it'll give me the latest unstable keyworded bugfix version of 1.2.* but doesn't go to 1.3 or above until those versions are considered stable

release :
1.7
1.8
1.9
2.0
2.1
...

for devs :
1.7.1
1.8.1
1.9.1
2.0.1
...

That's when it leaves beta, so 1.0.

>Sure, it works as a format, but it really doesn't contain any real meaning.
Version numbers are marketing tools, not information.

>all the little CVS advocates up here

35

You forgot Windows XP SP1, SP2 and SP3

>not information
For developers, it definitely is.
If some library is following semantic versioning, you would think your code that uses lib 2.1.0 will still work without problems on 2.2.0, but 3.0.0 might require changes.

1.9.1

2.0

1.10

version numbers aren't decimals

Nope, 2000 is build on top of NT. ME still used the ms-dos kernel as 95 and 98 did.

>version numbers are not information
This is how you tell everyone instantly that you're not a developer.

The next version can be anything you want.

Okay, let's split the difference. I see a few projects have taken to year.month.patchlevel naming schemes, where incompatibilities are never introduced when upping the patchlevel. To keep this nice and simple we only start unstable releases in odd numbered months, and stable releases in even numbered months.
What say? :^)

Maybe I've been in webdev too long and need to get out and into embedded.

1.9 build XXX

Windows 9 couldn't be a thing because some old software checked if the windows version was either 95 or 98 by looking for a 9 in the name of the OS.

Final 0.1

60
because chrome is version 60

37.00000000000042a

10.0.15063

finished versions
1.0
2.0

beta versions
1.2017.08.04.0
2.2018.12.23.0

nightly versions
1.2017.08.04.1
1.2017.08.04.2
1.2017.08.04.3

1.9.1a EAP

>HEXADCEIMAL BITCHES
THIS IS THE REAL FORMAT, EVERYTHING ELSE IS FOR PLEBS

1.10 if next release is a minor feature update.
2.0 if next release is significant enough to warrant it.

The only professional ITT

1.A

1.0111
1.1000
1.1001
1.1010

1.10

That sounds like some stupid rumor, I don't think it's even possible to get the OS version string like that using the WinAPI (and checking the string for the version would be ridiculously inefficient anyway). The WinAPI calls for getting OS version returns the OS version number, split into the major version, minor version, and build number. The major version for both 95 and 98 is 4.

Source: I still write software for 9x and i've never run into this problem at all

1.9.1RC3.7B~build3917350

1.10 obviously
or 1.0 again as the beta ended

The rumor originates from some retard on reddit and it got circulated by ""tech"" blogs, completely ignoring the fact that the code snippet is Java when the vast majority of software written for 9x would have been C or C++. I'm not surprised normalfags fell for it, but I'm surprised people on this board fell for it.

2.1 if they changed ui, 1.10 if not.

Seems like FOSS, not even versioning right.

It's Major.Minor.Patch, OP. You should be able to figure this out if you know what your working on. "Does this build have major changes? Does it contain minor changes? What's important to us? " The patch is the literal day-to-day.

1.10
Where 1.7: retrospectively become 1.07:
This is because point releases can't break compatibility.

...

>he doesn't use semantic versioning semver.org/

1.9.1
1.9.2
etc for patches and hot fixes, minor bug fixes, etc.
2.0.0 for the next major release.

There's always the possibility OP is a Pike, after all.

there is no wrong answer, version numbers are literally made up by the developer. There is no standard to follow.

t. IT engineer

>version numbers are literally made up by the developer. There is no standard to follow.
you're literally worse than Pajeets

4.20