mirror of
https://github.com/semver/semver.git
synced 2026-03-11 08:22:23 -05:00
FAQ Entry: compare to Romantic Versioning #366
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/semver#366
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 @steveklabnik on GitHub (Feb 11, 2019).
Originally assigned to: @steveklabnik on GitHub.
Requested here: https://news.ycombinator.com/item?id=19136592
Romantic Versioning is:
We should describe that semver is solving a slightly different problem.
@christian-weiss commented on GitHub (Feb 16, 2019):
Semver is pretty clear in the context of your link.
What § in semver do you want to improve?
PS: It feels stange to me that contributor of Backbone.js are saying that nearly every release introduces backwart-compatibility breaks... (i do not think semver is the problem here, it is maybe the architecture of Backbone.js that is the problem).
@Dunemaster commented on GitHub (Jun 20, 2019):
There is much sense in it. Personally, I would have liked to have an additional number in semantic version to reflect "product generation" or "marketing version".
Something like
GENERATION.MAJOR.MINOR.PATCH
Maybe in semver 3.0?
@runeimp commented on GitHub (Jun 24, 2019):
SemVer should never acknowledge marketing in any way. It's nice when marketing acknowledges tech specs "Version 2.0.0 is a complete architectural rewrite that enhances usability and efficiency." But the opposite is in no way in scope for SemVer "Version 2.0.0 achieves hyperspace++! We've gone plaid!". What would that look like? "Plaid.2.0.0, Hyperspace++.2.0.0, or QuantumTesseract.2.0.0?". If your looking at it from app development are you developing a library for Win32 and DirectX9 or Windows XP, Vista, 8, and 10? Windows 2000 was internally 5.0. Windows XP was 5.1. What version would the generation be? How does that help developers utilizing the product? The API is the only thing that matters. The marketing or generation version is just metadata that has zero impact to utilizing the API in most, if not all, cases. In certain instances it would be nice, or handy. And could work in a few types of product for a given API. But ultimately it's usually easy enough to lookup if your curious and just adds noise and possibly confusion to the process in most cases.
@jwdonahue commented on GitHub (Aug 16, 2019):
@steveklabnik, unless you intend to issue a PR or have further questions, please close this thread at your earliest convenience.
If you wish to publish a comparative study of SemVer vs Romantic Versioning, please feel free to do so. It does not seem me, relevant to the propagation of SemVer.
@jwdonahue commented on GitHub (Jan 17, 2020):
@steveklabnik, do you intend to issue a PR? If not, please close this issue at your earliest possible convenience.
@ljharb commented on GitHub (Jan 17, 2020):
@jwdonahue you realize they're one of the maintainers of the repo?
@jwdonahue commented on GitHub (Jan 17, 2020):
@ljharb, no I don't think I am. I may have been the most active contributor to the discussions around here the past few years, but I've never been one of the maintainers.
@ljharb commented on GitHub (Jan 17, 2020):
@jwdonahue no, i mean the person who created this issue that you're asking them to close. They're in charge of the repo, if they think this "comparative study" belongs here, then it belongs here.
@jwdonahue commented on GitHub (Jan 25, 2020):
@ljharb, ah, yes, I new that! Never really subscribed to the theory that the gods are infallible. Closing the thread, doesn't delete it from view. If you look around, you'll find that I have closed a few of my own threads, that either didn't get any traction or I don't have time to push a PR through to completion. Doesn't mean they aren't worthy of taking another look later on.
@ljharb commented on GitHub (Jan 25, 2020):
Sure. That also doesn’t mean the maintainers necessarily agree that actionable issues should be closed. Personally, i prefer issues in my projects to remain open forever until they are wontfixed or fixed, as i prefer discoverability to an artificially lower issue count.
@jwdonahue commented on GitHub (Jan 25, 2020):
Oh I agree. Nothing worse than hidden technical debt. But then I have a certain aversion to all forms of technical debt, including missing triage. A deep open issue queue is often an indicator of deep aversion to just admitting you're probably never going to fix most of those issues.
The tab is labelled "Issues", not "discussions". Issues are for tracking the things you have or need to address. Discussions are for... well, for discussions. A healthy open discussion group is a great source of work item generation. Nothing wrong with tracking both in the same database, provided the tooling and/or processes are capable of distinguishing between them. We could do that here with tags, as prescribed in the CONTRIBUTING.md file, plus maybe a few that aren't mentioned there, but the level of triage among the team members seems pretty weak (though @steveklabnik briefly exhibited more enthusiasm than some previous maintainers).
So when I ask someone to close a thread, it's really because my experience here, tells me it is not likely to lead to a PR, much less one that has any chance of being committed to the repo, and I can't create/apply tags. It's been my experience that productivity rates increase when the work queue is short enough, that there is some hope of clearing it.
@mk-pmb commented on GitHub (Oct 25, 2020):
Just for reference: There's a discussion about generation numbers in issue #213 already.
@tsjensen commented on GitHub (Oct 25, 2020):
http://sentimentalversioning.org/
Caution: satire 😉
@christian-weiss commented on GitHub (Oct 25, 2020):
@tsjensen thanks.
Switching from natural numbers to real numbers, to irrational numbers, and now to esoteric numbers.
Problem solved. We could close the ticket now ;-)
@steveklabnik commented on GitHub (Oct 28, 2020):
I don't really feel strongly that we should do this these days.