mirror of
https://github.com/semver/semver.git
synced 2026-03-22 14:10:15 -05:00
Time information #117
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/semver#117
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @nikkas on GitHub (Feb 2, 2014).
Problem:
Time information is important information which is missing from the semantic-versioning method.
New:
v2014.02.17-2.0.0
Solution:
The reader see the time of publication, understands the speed of evolution of the software, relates it with other events happened the same time, orders the versions easily etc...
@rlidwka commented on GitHub (Feb 2, 2014):
How about
v2.0.0+2014.02.17?@maximal commented on GitHub (Feb 4, 2014):
+1 for @rlidwka.
@vnagara commented on GitHub (May 13, 2014):
@rlidwka, No, This competes with build version.
@FichteFoll commented on GitHub (May 13, 2014):
@vnagara then do
v2.0.0-b.123.d.2014.5.11.t.11.18or the other way around, or without the letters.@zafarkhaja commented on GitHub (May 13, 2014):
I think using dates for major, minor and patch versions completely contradicts the very idea of the specification because SemVer is not about timing but rather about backward compatibility. On the other hand, date and time are pure metadata.
@crazedsanity commented on GitHub (May 13, 2014):
@zafarkhaja I completely agree. If one were to use "time information" to represent the version, then the first release of 2015 would appear to be incompatible with all prior releases. And that is not necessarily the case.
+1 for @rlidwka.
@synagonism commented on GitHub (Feb 12, 2017):
Revision.2017-02-12
name.m-m-p.yyyy-mm-dd
or
name-m.m.p-yyyy.mm.dd
@zafarkhaja This way we express the SemVer goal of backward compatibility AND we express the time past between the changes to understand the general environment of changes.
example (like semver): http://synagonism.net/hitp/#idMeta
synagonism (= nikkas)
Edited.2017-02-22
@zafarkhaja commented on GitHub (Feb 20, 2017):
@synagonism so, if I didn't miss anything, you use that format to version web pages, that is you use it to number content revisions? Then I'm not sure I understand what backward [in]compatibility means in this context. Perhaps SemVer is just not what you need for this. Perhaps it's better to invent a different versioning system to accommodate your specific needs.
On the other hand, SemVer could be the right tool to version HITP.
@jwdonahue commented on GitHub (Dec 5, 2017):
@nikkas, it doesn't appear to be very likely that this idea will ever be adopted. Unless you intend to actively pursue this issue, please close it at your earliest possible convenience.
@jwdonahue commented on GitHub (Jul 15, 2018):
@Haacked, time close this issue.
@jwdonahue commented on GitHub (Oct 8, 2018):
@nikkas, time data can be embedded in the build meta tag or package name. Also see VersionMeta and VersionSchema for an alternative scheme that could include time stamps.
Unless you intend to issue PR for this, please close this issue at your earliest possible convenience. Thank you.
@ukanuk commented on GitHub (Nov 10, 2022):
Does format
x.y.YYYYMMDDalready match Semver 2.0.0? I see nothing in spec about incrementing versions by one, it just says to increment according to incompatible changes/compatible new features/bugfixes. I suggestYYYYMMDDsince that's ISO date format and ensures the patch number always increases.