Provide the ability for the user to override the format used for tags (and therefore their parsing).
To do so, provide an option to override the tags as a string with placeholders and a regex with groups to parse back the tags.
Dedicated repo style:
Reminder: metav use v<major>.<minor>.<patch>-<sha><dirty?> format, e.g. v1.4.2 or v.1.4.3-0xF3423928DIRTY
Some user want to use tags like 1.4.2, to do so user would provide:
a string format of tag with placeholder like: %$1.%$2.%$3 with the index 1 as the major part of version, 2 the minor, and so on...
the regex to read back the tag like (\d+).(\d+).(\d+), again the group index to retrieve version data is predefined.
Monorepo style:
Reminder: metav use <module-name>-<major>.<minor>.<patch>-<sha><dirty?>
If no options are provided the existing behavior is applied with implementation using default format and regex.
Notes: Provide validation of format and parse string to check proper input and output of data.
Nota Bene: The feature is intended for advanced users that know what they are doing and are able to provide consistent format and regex to read back the tags...
The two options must be provided together consistently for display, spit and release tasks.
Here is the initial conversation with slimslenderslacks that leads to this refactoring:
I'm working on some projects where the "v" prefix in the tag is breaking some other downstream workflows.
I was wondering whether it might be a useful addition to make that prefix an option:
So, an example could be:
clj -m metav.release --prefix "not_v"
In my case, I wanted the prefix to be an empty string so:
clj -m metav.release --prefix :none
was what I actually wanted to use.
Thanks for the work on this Jeremie!
Hi Jim,
Thanks for your PR! Yes sure I think it can be pretty useful to allow user to configure the way tags are made up!
To extend the refactoring of the prefix things. What do you think of providing an override of both the format and parse function with a placeholder string and a regex string for respectively generating and reading a tag?
Jérémie.
Hi Jérémie
Yes, I think the ability to control how tags are formatted (and parsed) would work! It sounds like a more flexible approach too. In my case, I'm hoping to be able to have a tag with no prefix (not even a 'v') when the module is at the root of the Repo. I'm actually more accustomed to tags that start with 'v', but I'm working on a project with a strange requirement on tag formats. I guess that speaks to your point about just making format/parse extensible.
I would offer to try to implement something here but it sounds like you've got an idea. I will certainly pull this and test it out for you though! At my company we're building a product to support serverless dev tooling, and supporting both clj, and cljs on Node.js. I've been "injecting" (by PR) metav into all of our clj/cljs repo's deps.edn files because it's just one of those tools that instantly improves your workflow.
I think you can probably just close this PR but let me know if I can help/test something for you.
Provide the ability for the user to override the format used for tags (and therefore their parsing). To do so, provide an option to override the tags as a string with placeholders and a regex with groups to parse back the tags.
Dedicated repo style:
Reminder: metav use
v<major>.<minor>.<patch>-<sha><dirty?>
format, e.g.v1.4.2
orv.1.4.3-0xF3423928DIRTY
Some user want to use tags like1.4.2
, to do so user would provide:%$1.%$2.%$3
with the index 1 as the major part of version, 2 the minor, and so on...(\d+).(\d+).(\d+)
, again the group index to retrieve version data is predefined.Monorepo style:
Reminder: metav use
<module-name>-<major>.<minor>.<patch>-<sha><dirty?>
If no options are provided the existing behavior is applied with implementation using default format and regex.
Notes: Provide validation of format and parse string to check proper input and output of data.
Nota Bene: The feature is intended for advanced users that know what they are doing and are able to provide consistent format and regex to read back the tags... The two options must be provided together consistently for display, spit and release tasks.
Here is the initial conversation with slimslenderslacks that leads to this refactoring: