Add support for basic version requirements #63
Conversation
With any project, eventually you get to a stage where you have configuration defined that works on a specific version of your software. Upgrading between versions usually requires some effort but it's rolled out when it's needed. This becomes even more difficult working in a team where people can have different versions of the software that you use based on how often they like to update their systems. To handle these scenarios, you introduce some sort of versioning that defines what versions you want the configuration to operate with and the users then need to meet those requirements. This introduces a basic concept of the versioning for IAMy. The logic is pretty straight forward. - If you find a `.iamy-version` file, use the version defined in it. If not, continue on. - If the `.iamy-version` file contains a version number, compare it to the local version and ensure that the version in use meets the minimum requirements to operate. If it doesn't, inform the user of the discrepancy and what is required. 99designs#62 proposes quite a few more coditions to restrain the version however I don't think that's required for majority of use cases. I think defining a minimum version covers most of the sharp edges we've encountered. But, we can always make this more perscriptive if needed. Closes 99designs#62
|
If you'd like to test this locally, you can pull it down and try the following commands for the various options: echo "2.1.1" > .iamy-version
go build -ldflags "-X main.Version=1.2.3" -o dev-iamy
./dev-iamy pull rm .iamy-version
go build -ldflags "-X main.Version=1.2.3" -o dev-iamy
./dev-iamy pull echo "2.1.1" > .iamy-version
go build -ldflags "-X main.Version=1.2.3" -o dev-iamy
./dev-iamy pull --debugI purposefully use |
|
@mtibben Any objections from you on this one? I was bit by this again today (almost 12 months to the date of raising it 😂 ) |
|
@patrobinson I've just gone through this again and it's already output as a debug statement when #63 (comment) provides some local testing steps if you'd like to confirm for yourself. |
|
@jacobbednarz sorry for taking such a long time to get back to you. running a dev build of this presents a problem, Semver returns the default empty value |
This is something we should probably fix. The semver specification does allow build metadata which seems like a good fix here and would be compatible. Something like I had added the additional check for bypassing |
|
Just above the build metadata section there is also a section on prerelease 🤦 This is almost what we have but need to make the formatting match the expected input and it should be 👌 . Build metadata might be more appropriate as it's a sha but I'm not particularly phased. |
|
The requirements on pre-release appear to allow our version format:
The issue is the When I try using golang.org/x/mod/semver then it behaves as expected. Can we switch to using this library? |
|
Ah gotcha, I totally missed the little trailing hyphen in there. I don't feel strongly about swapping the library in use but the return values for
If it's just the "v" throwing this off, we can ignore for the purposes of the comparison. |
|
I don't have a strong opinion, but I'd default to the golang module package due to the implied support of using a golang library. |
|
There have been a few requests around wanting to configure optional features
I wonder if we should consider creating a more general |
|
@mtibben Considering the amount of time something like using a consistent version in a project has taken to get to this point (> 12 months), I'm hesitant to bring in more scope. With the included examples, I am also wondering whether explicit command arguments are a better fit (something like |
|
I think it's tempting to combine these two requirements but I'm also tempted to get this particular functionality out and ship those seperately. @jacobbednarz What can I do to help get this PR over the line? |
|
Playing devils advocate, do tools like https://github.com/asdf-vm/asdf fill this gap better? |
|
As an asdf user - I don't think so. This is something that needs to be controlled by the "owner" of the particular iamy workspace and enforced by the tool to be effective - whereas asdf is very much "opt in". (also bitten by this quite a few times, has had team members bitten, work alongside jacob & pat) |
|
You could use |
|
@mtibben are you happy for this PR to get merged? |
|
@patrobinson We still need to fix the version comparison. I'll look to either swap it out for stdlib today, or update the comparison to account for it. |
|
Sorted, it will work for |
|
@mtibben what's your thoughts? |
|
ping @mtibben |
|
closing due to necromancy. if someone decides to persue this, feel free to cherry pick the commits from here. |
Merge in 99designs/iamy#63 (jacob's .iamy-version thingy)
With any project, eventually you get to a stage where you have
configuration defined that works on a specific version of your software.
Upgrading between versions usually requires some effort but it's rolled
out when it's needed. This becomes even more difficult working in a team
where people can have different versions of the software that you use
based on how often they like to update their systems.
To handle these scenarios, you introduce some sort of versioning that
defines what versions you want the configuration to operate with and the
users then need to meet those requirements.
This introduces a basic concept of the versioning for IAMy. The logic is
pretty straight forward.
.iamy-versionfile, use the version defined in it. Ifnot, continue on.
.iamy-versionfile contains a version number, compare it tothe local version and ensure that the version in use meets the minimum
requirements to operate. If it doesn't, inform the user of the
discrepancy and what is required.
#62 proposes quite a few more coditions to restrain the version however
I don't think that's required for majority of use cases. I think
defining a minimum version covers most of the sharp edges we've
encountered. But, we can always make this more perscriptive if needed.
Closes #62