Add extra major and minor tags to each release

[fernandocollova]

Hi everyone,

First of all, thanks for this amazing tool. Believe it or not, I just found this last week, after some heavy googling, and I can't understand how it never appeared in previous searches.

Anyway, getting to the issue.

I usually manage two extra set of tags on the projects I use semver on: For a 1.5.1 release for example, I would have a 1.5.1 tag, a 1.5 and a 1 tag pointing to the same commit. And, if I happen to make a 1.5.2 release, I would delete and recreate the 1.5 and 1 tags, pointing them to the same commit 1.5.2 is on.

This is specially useful for maintaining multiple versions in things like rest APIs, so that you can build your code tagging, for example, the 1.5 series, and always get the latest fixes.

So I was wandering, would some code like this be of any interest to you, to add that functionality?

Again, thanks for this tool
Fernando

[markchalloner]

Hi Fernando,

I wouldn't add this code to the core as the functionality doesn't adhere to the semver spec and would force all users to accept these tags.

I would however appreciate a plugin. Please see the examples to get started.

Mark

[fernandocollova]

Mark, thanks for your answer.

Yes, that's a good point. Although I think adding it wouldn't be against semver, it would clearly be an "extra" you would be imposing on people and I get that's not a good idea.

Regarding the idea to do a plugin, I can totally do that, however, I didn't even think about going that way because, from the documentation, I understood that plugins were meant to check stuff to allow or deny tagging.

Is that the case or should I go forward with the plugin? Also, I was thinking about submitting as a plugin some code I use not to check, but to directly change the version of a python setup.py file and commit it before tagging. Would something like that be welcomed too?

Thanks Fernando

[markchalloner]

Agreed, the documentation could be updated to make it clear that plugins can run arbitrary commands (akin to git hooks) and the return is just a way to block tagging.

Both plugins sound off to me. It might be worth putting in place a naming scheme that more accurately describes what the plugin does e.g.: keepachangelog_check.sh and setuppy_update.sh.

[fernandocollova]

Well, I just created a merge request for the setuppy_update.sh plugin, and I'm realizing something when converting my first proposal into a plugin. As far as I can tell, there is no warranty of the orders in which plugins will be executed.

For what I can see, they will execute in the order find finds them, which, according to StackOverflow can be basically anything.

And, that means I have no warranty that, for example, my setuppy_update.sh plugin will run before the one that creates the extra tags of the release. Which means, I could be tagging something other than the last commit.

Will adding a sort command somewhere be something you would be willing to merge? Then, you can number your plugins (like many programs do for config files) so that you can assure they run in the order you expect them to run.

Thanks, Fernando

[markchalloner]

Hi Fernando,

Great point, thanks for researching this.

I agree with sorting and running the plugins by name, though it needs to be Mac and Windows compatible too.

Cheers
Mark

[fernandocollova]

Hello again,

I finally got time to finish the sorting code. It sorts the plugins taking into account the first 2 characters of it's name, doesn't reject plugins without numbering, but also doesn't guarantee execution order if you don't number all your plugins. I think it's a reasonable compromise for people that simply don't care about the order their plugins are run, and people who do care.

I tested it on my Fedora laptop, but unfortunately I don't have at hand a Windows PC to test it, and getting my hands on a Mac will be quite more difficult.

Do you know of anyone that could test this? At least on MacOS? The feature branch is here and it's missing a documentation update, but I'll do that as soon as I know it works on Windows and Mac, just in case I need to change anything.

Thanks, Fernando

[markchalloner]

Hi Fernando, the behaviour on Mac seems the same as Linux with these sort parameters, however I'm not sure this is going to work as intended. find returns the full path so your sort will be acting on the first two characters of the path, e.g:

$ find /tmp/plugins -maxdepth 1 -type f | sort -k1.1n,2.1n
/tmp/plugins/001.sh
/tmp/plugins/01.sh
/tmp/plugins/100.sh
/tmp/plugins/10.sh
/tmp/plugins/1.sh
/tmp/plugins/a001.sh
/tmp/plugins/a01.sh
/tmp/plugins/a100.sh
/tmp/plugins/a10.sh
/tmp/plugins/a1.sh
/tmp/plugins/a.sh

You should be able to remedy this by -exec basename {} \; (but note the non-numerical sort of {100,10,1}.sh). You will have to add ${plugin_dir}/ back in the echo:

$ find "${plugin_dir}" -maxdepth 1 -type f -exec basename {} \; | sort
001.sh
01.sh
100.sh
10.sh
1.sh
a001.sh
a01.sh
a100.sh
a10.sh
a1.sh
a.sh

The other issue that I'm finding is that sort -n orders alphas before numerals:

$ find "${plugin_dir}" -maxdepth 1 -type f -exec basename {} \; | sort -n
a001.sh
a01.sh
a100.sh
a10.sh
a1.sh
a.sh
001.sh
01.sh
1.sh
10.sh
100.sh

A possible hack would be to run the sort twice, once on numeric-prefixed files, then once on alpha-prefixed files:

plugins=$(find "${plugin_dir}" -maxdepth 1 -type f -exec basename {} \;)
for plugin in  $(grep "^[0-9]" <<< "$plugins" | sort -n); do
# ...
for plugin in  $(grep "^[^0-9]" <<< "$plugins" | sort); do
# ...

[fernandocollova]

Hi Mark,

Thanks for your comments, and, I really should've tested this more. As it worked (just by chance it seems) on the two cases I had, I assumed it was ok and pushed it. Sorry about that.

Regarding your proposed fixes, I'll add the basename sorting, and I think a better approach to sorting the alpha-prefixed plugins after the numeric ones is to use the -V option of sort, which orders first based on a regex, an then according to the byte value of the string on the C locale.

The regex ordering as far as I cloud test, doesn't impact the proposed numbering scheme, and if anything, adds an extra way of naming plugins, but most importantly, it is consistent, because it ignores the user's locale and always uses the C one, so we shouldn't stumble upon someone using an unforeseen locale for which the sorting fails.

I'll polish my code a little bit tomorrow and I'll push the changes above to my repo. Please let me know if you see any problems with the -V approach, or anything else for that matter.

Greetings, Fernando

[fernandocollova]

Here is the link to the changed line

[markchalloner]

Hi Fernando, unfortunately only gnu sort has the -V argument, so this would break for OSX users 😞.

[fernandocollova]

Oh, that's most unfortunate. I even checked the FreeBSD man pages to have a reference to another OS and it was there.

Well, I guess I'll add the grep and push again. Thanks for the input.

[fernandocollova]

Just added the grep, and since I now use "general numeric sort", I also added a LC_ALL=C before both sorts.

As usual, any inputs are welcomed
Fernando

[markchalloner]

Thanks for the contribution!