Hi there! Thanks for writing self_update!
I'm playing around with it and I noticed that the release prefix is currently not configurable: https://docs.rs/self_update/0.27.0/src/self_update/backends/github.rs.html#55. Versions beginning with v are not valid semver, and using v is more of a convention than a hard rule. Other projects might use their own prefixes in their tag names (e.g. my-package-1.3.4, common in monorepo situations where multiple binaries are released), or no prefix at all (e.g. 1.3.4).
Moreover, if tag names begin with v but don't use the v1.3.4 naming scheme, they will have unexpected results. For example, if a tag is called very-cool-package-1.3.4, its version will be returned as ery-cool-package-1.3.4. This seems non-ideal.
My proposed solution would be to add a configuration, e.g. fn tag_prefix(&str). This can be "v" by default, but could also be set to "my-package-" or even "". You could then even filter out tags that don't match the prefix.
This would be a breaking change.
Hi there! Thanks for writing
self_update!I'm playing around with it and I noticed that the release prefix is currently not configurable: https://docs.rs/self_update/0.27.0/src/self_update/backends/github.rs.html#55. Versions beginning with
vare not valid semver, and usingvis more of a convention than a hard rule. Other projects might use their own prefixes in their tag names (e.g.my-package-1.3.4, common in monorepo situations where multiple binaries are released), or no prefix at all (e.g.1.3.4).Moreover, if tag names begin with
vbut don't use thev1.3.4naming scheme, they will have unexpected results. For example, if a tag is calledvery-cool-package-1.3.4, its version will be returned asery-cool-package-1.3.4. This seems non-ideal.My proposed solution would be to add a configuration, e.g.
fn tag_prefix(&str). This can be"v"by default, but could also be set to"my-package-"or even"". You could then even filter out tags that don't match the prefix.This would be a breaking change.