BUG: --show-latest-stable 0.XX does not return expected version
Closed this issue · 9 comments
TFSwitch Version: 0.13.1221
Mac OS 12.4 (M1)
When calling the following:
tfswitch --show-latest-stable 0.11
We use to get the latest version of terraform 0.11 returned:
0.11.15
With the latest tfswitch updates, we see the following:
Matched version: 0.15.5 0.15.5
I expect this is a recent bug with latest changes.
I think the behavior you desire was a bug that has since been fixed. #226
The "new" behavior seems correct to me: https://www.terraform.io/language/expressions/version-constraints#-3
~>: Allows only the rightmost version component to increment. For example, to allow new patch releases within a specific minor release, use the full version number: ~> 1.0.4 will allow installation of 1.0.5 and 1.0.10 but not 1.1.0. This is usually called the pessimistic constraint operator.
I haven't tested this personally but that implies ~> 0.11 translates to >= 0.11.0, < 1.0.0 which correctly matches 0.15.5
So I think what we should instead remove the hard requirement for x.x and allow specifying a full version such as 0.11.0 which would result in 0.11.15
This was the documentation I was going off https://tfswitch.warrensbox.com/Quick-Start/#show-latest-implicit-version-for-stable-releases
Showing the latest stable version of a particular version specified seems to make total sense getting anything else above that doesn't unless that flag has a way to specify an upper limit to not get the absolute latest that I may or may not be prepared to support in my projects for no particular reason.
I'm hoping it is just a bug as I have a bunch of automation that relies on that command flag and the behaviour specified in the documentation.
The way around this would be to also specify a patch version (i.e. 0.11.0) which currently isn't supported in tfswitch.
I'm with ya that the functionality changed with the PR I linked, but that's also in line with how terraform would directly handle it so it makes sense that this project would want to have similar behavior.
Takeaways for me are to update the docs to reflect the new (corrected) behavior and also add support for more than x.x for command flags because as-is I don't think you can get what you want.
The way around this would be to also specify a patch version (i.e. 0.11.0) which currently isn't supported in tfswitch. I'm with ya that the functionality changed with the PR I linked, but that's also in line with how terraform would directly handle it so it makes sense that this project would want to have similar behavior.
That's fair enough. Is there any plan to support specifying the patch version anytime soon?
Worst case, would I be able to revert the tfswitch version to where the original functionality I was relying on still functions or was there upstream changes with Terraform's releases API that would prevent that functionality from continuing to work?
I appreciate your responses.
Is there any plan to support specifying the patch version anytime soon?
Contributions are very welcome. As it seems like @warrensbox has pretty much little time to pro-actively implement features at the moment.
Maybe @jukie would be keen to look into this 🤔
Worst case, would I be able to revert the tfswitch version to where the original functionality I was relying on still functions or was there upstream changes with Terraform's releases API that would prevent that functionality from continuing to work?
I think reverting to that previous version would end up with broken TF binary download =(
Yep, checked a few past versions and they aren't working with that flag either.
So, I've reworked my automation to not rely on this tfswitch flag anymore. It was pretty loose to rely on this but it was ideal at the time. My change will be easier to maintain and won't rely on tfswitch incase anything ever changes again.
I don't think things will change again, as since the change @jukie told about tfswitch is aligned with how Terraform compares and parses semantic versions and uses the same Go library for this (which @jukie PR'ed to the other day as well I guess).
@matthewlynden Should we close this issue by this time?
Yeah I am happy for this to be closed. Thanks!