-
Notifications
You must be signed in to change notification settings - Fork 146
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support Semantic Versioning #96
Comments
@andsens two questions for you.
|
I think we should just keep it at the pull command and add a prompt.
Great idea! Of course it should, haha. I didn't even think of it that way around, but it totally makes sense.
I was actually thinking more along the lines of tags on certain commits of a branch. That way homeshick can still check out the latest updates for a specific major version without having to look at the a file in every commit. I'm sure we can come up with a convoluted git one-liner for this :-) |
I like the tag idea! I didn't think about the multiple major releases scenario. Good catch. |
Should the tag convention have a v prefix? e.g. |
I'd go with the flow here. Whatever other big projects that use semver agree on is fine with me :-) |
Github suggests using the v at the beginning, but I haven't used the v in my projects since I didn't know about the convention till recently. Since homeshick doesn't have any tags, you can see github's suggestion for the v prefix here: https://github.com/andsens/homeshick/releases Maybe we should just the ignore alpha characters and just look for a |
v prefix it is!
Nah, if there is a prefix one should use then it must be there. I don't like catering to standard implementations that are almost followed (more like hate it, I'm a web developer). It's just too much hassle, complicates the code and allows for breakage in the future. |
I'm thinking about working on this sometime in the near future and have been thinking about how it should work. Reading through this I think it answers the majority of questions I have come up with over the last few days. I still have two questions though.
|
any progress in this? |
I have not been able to work on this. I also no longer use homeshick so am no longer in a good place to implement this feature. Feel free to close the issue 😄 |
We need to support a semantic versioning update system for homshick in order to mitigate the risk of breaking user's castles with a major release (i.e. potential breaking changes). In essence we need to change the way pull works with homeshick. If the new version homeshick that is being pulled is a new major version (breaks backwards compatibility). It would prompt the user, that there are major breaking changes and that they should read the change log before updating. After they've done so they may
homeshick update
.I'm impartial as to the
homeshick update
command idea. A better idea might be prompting the user whether or not we should continue with the pull if it is a major release. This would require that thepull
command have an-f
where it wouldn't prompt for version changes.We should implement this feature with convention. So that it can be applied to any castle. Maybe it could use a VERSION txt file in the root of the repo that would be a semantic version to check.
The text was updated successfully, but these errors were encountered: