feat: Support and remember version range specifiers (>=3.2,<4) when updating

[scastria]

I would like to make it harder for customers of my template to absorb breaking changes. The first number in semantic versioning is MAJOR and should be changed for breaking changes. If I make a breaking change to my template and tag it with a new MAJOR version number, I want the user who runs copier update to have to jump through extra hoops before updating to the breaking change version.

Similar to Terraform, allow the user to specify a version specifier, like 3.x or 3.2.x. This could be stored in the answers file alongside the _commit value. So _version_spec could be v3.x and _commit could be v3.1.2. If I release a new template version as v3.2, then the next time the user runs copier update, copier will know it can upgrade to v3.2 since the user said they wanted any version that starts with 3 MAJOR version number. If I release a breaking change as v4.0.0, then the next time the user runs copier update, nothing will happen since v4.0.0 doesn't match the user's request version spec of v3.x. However, copier update could let the user know that a newer version exists. The user could then run copier update --version-spec v4.x which tells copier to allow the upgrade to v4.0.0 and to update the answers file with the new _version_spec value for the next copier update.

[yajo]

The feature itself makes sense, however I'm more in the side of automating stuff.

ATM you have the _migrations option that let you trigger some commands before and after migrating the project to a certain template version. My option has always been to use that to automate migration to higher versions when something wasn't fully backwards-compatible. You could do the same, or you could open some interactive workflow for your specific stuff.

That wouldn't force the user to migrate to a bigger major version only by demand, but would help them having a successful update.

Would that be enough for your use case?

[scastria]

I don't think so. I think it would really be better to allow the user to specify some kind of version spec to control more the upgrades. Of course, this is just my opinion. Maybe others can comment.

[pawamoy]

I'm tempted to say: sure, why not have the same control over updates as with regular PEP440 specifiers?

_accept_template_versions: ~=3.2

[yajo]

fwiw I don't like the idea of handwriting that stuff in the answers file, because that violates the purpose of those # File generated by copier; DO NOT EDIT MANUALLY comments that are very helpful.

I think that the cleanest implementation would be to add some extra commands to the CLI/API:

• copier update-major
• copier update-minor
• copier update-patch

However that would kill the purpose of using PEP 440 which is not limited to major.minor.patch as semver. Maybe something like copier update-compatible 2 which asks for 2 sections compatibility (== minor)? Maybe both, making the 1st 3 ones aliases to the latest one? Maybe a flag in copier update? 🤔

[scastria]

Agreed. I wasn’t suggesting the user edit the answers file, but to use a new switch on the copier update Command like —version-spec or something similar.

But I am not too picky on how it is implemented, just as long as the feature exists. :)

[yajo]

I changed the title, I think the simplest approach is to just reuse the --vcs-ref option and add support for PEP440 specifiers there.

[scastria]

Possibly, but I think the answers file needs to record both the actual version used for the last update and the version specified desired by the user. So if the next time the user wants to update, he can just say copier update without anything else and it will do the right thing. If you make the user always have to specify a vcs-ref during an update, I don’t think it will be good enough as now the user has to remember what version specifier he wants every time.

[yajo]

Well, then it must be recorded indeed, but it must be copier who writes it to the answers file, so we need a flag.

[shusriva]

Hi @scastria , I am also working on the same use case. @yajo Do we have any solution now for this issue ?

[yajo]

Sorry, not for now.

The implementation is:

• One new CLI flag: --version-subscription with its corresponding API arg
• If passed, check it's a valid PEP 440 specifier.
• Store it in copier answers file under a new key: _version_subscription
• when running copies update, filter incoming tags with it to findthe desired release.

However nobody volunteered yet to implement it.