mirror of
https://github.com/semver/semver.git
synced 2026-07-10 19:50:47 -05:00
[GH-ISSUE #159] SemVer case study #4346
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/semver#4346
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 @bessarabov on GitHub (Aug 29, 2013).
Original GitHub issue: https://github.com/semver/semver/issues/159
I'm using SemVer in my library. I'm not sure that I did one thing correct, so I want to ask a question if what I did is best SemVer practice, or I could handle this situation better.
I have a library (if you are interested, here is the link) that works with some https site. I give that library login and password and it returns some structured data. Everything worked ok.
But one day the library stopped working. I made some investigations and found out that there is the problem with SSL certificate of the site. The certificate has expired and my library throwed exeption and did noting. I have created the bug report for the site owners and I have fixed my library (so it worked with incorrect SSL certificate) and released new version with the change of the MINOR version level.
Some time passed and the site owners has fixed the SSL bug. I have updated my library so it checks that the certificate is correct. I've released new version of the library with change in MINOR version level.
Have I done everything correct? Is it what SemVer recomends do in such situations? Is right that i have changed the MINOR level? Or maybe I should handle this situation in some other way?
@Oxymoron290 commented on GitHub (Sep 7, 2013):
If the fix to support incorrect SSL Certificates was known to be temporary, It may have been better to use a pre release tag such as x.y.z-rc1, and then when the issue was resolved revert back to x.y.z, this keeps the favorable version x.y.z with precedence. However this is my personal view on the issue.
Strictly following the specification, this fix should have been initially identified as a PATCH which is
incremented if only backwards compatible bug fixes are introduced. A bug fix is defined as an internal change that fixes incorrect behavior.And when the issue is resolved by the hosting provider, the MINOR version would be incremented according to
[Minor version Y] MUST be incremented if any public API functionality is marked as deprecated.and the PATCH would reset to 0.
However, your solution is valid according to the specification where
[Minor version Y] MAY be incremented if substantial new functionality or improvements are introduced within the private code. It MAY include patch level changes.Regardless, the issue did not arise from an issue with your code, but the environment it was in. Faced with this situation, I would have made the function, and set it as available in a configurable parameter set aside in some configuration file or database entry to be set by the system administrator. Then released that with a MINOR version. This will allow you to go back and forth should the issue present itself again in the future.
Hope this answers any questions.
@wahidkabir2013 commented on GitHub (Sep 8, 2013):
Thanks
@bessarabov commented on GitHub (Sep 8, 2013):
@Oxymoron290 Thank you!
I love your idea that I should made this behaviour configurable. In that case I had to release only one new version. For now everything is working and I will not implement this behaviour, but if the situation repeat I will do it.
I don't like your other idea about x.y.z-rc1. I think this is more like a hack and there are often problems with hacks. This library is open sourced, so I wanted to fix it to all who uses it (actually I'm not sure that anybody uses it, but it does not matter) and releasing rc1 will solve the problem for me but the publicly released version will be still broken.
I like SemVer much and this it the most worked out thing, but after your post I understood the small thing I don't like about SemVer. The same change different people can mark as Minor or Patch, and I think this is a bad thing. The more things are standard the simpler is to understand them. Not sure if this can be fixed, maybe SemVer has to have more case studies with the correct way of doing things?
@jwdonahue commented on GitHub (Dec 2, 2017):
@bessarabov , if your question has been answered and you have nothing further to add here, please close this issue at your earliest possible convenience.
@jwdonahue commented on GitHub (Oct 8, 2018):
@bessarabov, can you please close this thread? We're trying to eliminate open threads that have been answered and are unlikely to result in pull-requests. Thank you.