Skip to content
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

Open
squaresurf opened this issue Apr 24, 2014 · 10 comments
Open

Support Semantic Versioning #96

squaresurf opened this issue Apr 24, 2014 · 10 comments

Comments

@squaresurf
Copy link
Contributor

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.

@squaresurf
Copy link
Contributor Author

@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?

@andsens
Copy link
Owner

andsens commented Apr 24, 2014

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 :-)

@squaresurf
Copy link
Contributor Author

I like the tag idea! I didn't think about the multiple major releases scenario. Good catch.

@squaresurf
Copy link
Contributor Author

Should the tag convention have a v prefix? e.g. v3.23.52

@andsens
Copy link
Owner

andsens commented Apr 24, 2014

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 :-)

@squaresurf
Copy link
Contributor Author

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.

@andsens
Copy link
Owner

andsens commented Apr 24, 2014

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.

@squaresurf
Copy link
Contributor Author

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.

  1. If there are branches and tags in a castle, should this filter out release tags that aren't in the currently checked out branch?
  2. 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?

@MaxPeal
Copy link

MaxPeal commented Dec 20, 2019

any progress in this?

@squaresurf
Copy link
Contributor Author

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 😄

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants