mirror of
https://github.com/semver/semver.git
synced 2026-07-11 04:52:47 -05:00
[GH-ISSUE #386] Handling of text/layout changes/minimal enhancements and public vs private projects #7262
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/semver#7262
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 @adamreisnz on GitHub (Aug 4, 2017).
Original GitHub issue: https://github.com/semver/semver/issues/386
Under semver, how does one handle things like:
For me they usually fall in a gray area between a patch and minor version, but I was wondering if there's an accepted consensus, or whether it matters that a project is public or private.
For example neither a text change or a layout change "add new functionality to the API" strictly speaking, nor are they really bug fixes. Unless you consider the old text/layout a "bug". So does that mean layout/text changes can be done in patch versions?
The semver specification seems primarily focussed on public packages with publicly consumed API's, but when applied to private projects, it can become harder to differentiate the boundaries between PATCH/MINOR/MAJOR and one might even shift the boundaries altogether, e.g. release patch versions with enhancements, minor versions with larger features including API changes, and major versions only when there are drastic changes to the consumer facing part of the application/complete overhaul.
Curious to hear your thoughts.
@FichteFoll commented on GitHub (Aug 4, 2017):
Unless I can see users relying on a certain feature I add, I just default to a patch release. None of the things you list strike me as something a user would rely on, so I'd go with patch for all of them.
The layout thing depends largely on the application and is very specific, so I can't really say anything about that. Note, however, that semver was designed primarily for dependencies (i.e. libraries used by other applications) and not end-user-facing applications. It can be adapted for this somewhat, but the spec is deliberately unclear about situations like these.
@adamreisnz commented on GitHub (Aug 5, 2017):
Yes, that's mostly what I do now, for both private and sometimes public projects as well. I guess it just requires a pragmatic approach.
Thanks!
@raginmari commented on GitHub (Nov 12, 2017):
Would adding Carthage support (for example) be a patch or minor version increment? It does not add to the public API nor does it alter it, but it is not a bug fix either. It does not affect the code in any way, actually.
Carthage requires a semver tag, so I can't just leave the version number as it is, move the tag and basically update the current version, right?
@jwdonahue commented on GitHub (Nov 28, 2017):
This is another instance of "what should get versioned". If the docs changed, their versions should get bumped appropriately, but some thought has to go into the impact at the distribution package version level. If the docs were woefully incomplete say when 1.0.0 of the package was released, and you put a lot of effort into them, you have every right to brag about major new features, even if they are pure document changes, but you might not have to; if the new docs don't expressly prohibit some known usage patterns that have caused problems for product support staff. If they do, then you probably owe your customers a major version bump on the package.
@jwdonahue commented on GitHub (Jul 12, 2018):
@adamreisnz, any further question on this matter? If there are no outstanding actionable asks here and your questions have been answered, please close this issue at your earliest possible convenience. Thank you.