homeshick
homeshick copied to clipboard
Support Semantic Versioning
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 the pull
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.
@andsens two questions for you.
- Do you like the prompt solution with the
-f
flag for the pull command? - Are you ok with the VERSION file in the root of a castle being used for this?
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 the pull command have an -f where it wouldn't prompt for version changes.
I think we should just keep it at the pull command and add a prompt.
We should implement this feature with convention. So that it can be applied to any castle.
Great idea! Of course it should, haha. I didn't even think of it that way around, but it totally makes sense.
Are you ok with the VERSION file in the root of a castle being used for this?
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. v3.23.52
Should the tag convention have a v prefix? e.g. v3.23.52
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 #.#.#
pattern. The one drawback might be that it would slow down the pull command. Not sure how much though.
Since homeshick doesn't have any tags, you can see githubs suggestion for the v prefix her
v prefix it is!
Maybe we should just the ignore alpha characters and just look for a #.#.# pattern. The one drawback might be that it would slow down the pull command. Not sure how much though.
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.
- If there are branches and tags in a castle, should this filter out release tags that aren't in the currently checked out branch?
- Should we add a
-l
flag or the like that will move the castle to the latest commit even if it is newer than the newest tag?
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 :smile: