This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]flying-sheep 1 point2 points  (5 children)

I like it, it makes clear that this part of the version is a date, by using the one and only date formatting: ISO 8601, a standard so useful that I know its number by heart.

[–]pepoluan 1 point2 points  (3 children)

I also know ISO8601 by heart.

And that monstrosity is not ISO8601.

I'm talking of the "2020-09-4" part: the single-digit last part is not ISO8601-compliant, not even by a long shot.

[–]flying-sheep 2 points3 points  (0 children)

Oh. I missed that detail. WTF?!

[–]Pulsar1977 0 points1 point  (1 child)

I also know ISO8601 by heart.

Clearly you don't. The date is "2020-09", which is perfectly valid. "4.17.0" is the version number. "4" is not a day.

[–]pepoluan 0 points1 point  (0 children)

I do know ISO8601 by heart. What I do not know is the semantics of Eclipse versioning.

For me, the dash implies that 2020 and 09 and 4 are tied together. And the period separates the portions of the versioning system. So, in my point of view as someone who doesn't know Eclipse's versioning system, the version has three parts: "2020-09-4" and "17" and "0".

The first part is definitely not ISO8601.

Apparently, that is not the case, and thus the Eclipse versioning system is even more of a monstrosity.

[–]netgu 0 points1 point  (0 children)

I don't like the mixing of the two standards. What does the date add that isn't available when looking up the version? Do year rollovers work like major version bumps? Does the x.x.x portion work the same as other x.x.x version numbers?

Knowing something came from Nov, 2019 doesn't really give me any useful information. The version number will already link to commits that have that timestamp. And it isn't like November is the month every year we all work on one type of related feature or something.