Add major version at release

[s-weigand]

To make it easier for users to adapt to breaking changes in the action, having major version tags to rely on, instead of master, is a good thing for users and developers.
I recently discovered this awesome action which does exactly this, fully automated on relese if you set you workflow up like this.
Just wanted to share that info and action, to save you the research.

P.S.: Thanks for this action, it works like a charm 😄

[webknjaz]

fully automated on relese if you set you workflow up like this .

This sounds nice but is a security hazard (explained here why #27 (comment)). I'm thinking about how to solve this best but don't have a timeline for completing such setup.

[s-weigand]

I see your point and thanks for sharing the post.
But on the other hand, IMHO you have to trust some organizations like github or pypa, that the tools they publish aren't malicious. Actions from pypa aren't just 'random @github actions found on the markedplace' as mentioned in the post.
In theory you would have the same security problem when updating twine.

To minimize the risk that a 3rd party action injects malicious code into your release, you could just fork release-github-actions. This way you have the control over what is done on release.

It might still be worth mentioning the security risks and encourage users to use the commit sha, since as the post stated patch version tags are as hazardous and major versions.

[hugovk]

A v1 tag is technically insecure, but so is v1.4.1.

A lack of v1 means people use master, arguably less secure than a tag.

Of course people should use a SHA or fork but they don't...

(The pro tip on the README recommends SHA or tags over master. It should recommend SHA/fork over tags and master.)

[webknjaz]

@hugovk fair enough! I guess I should find time to think through the options and finally solve this request once and for all...

[pradyunsg]

@webknjaz Have you thought through this?

I think it'd be good to have a v1 tag, following the model that actions/ repositories (as well as basically every other popular action that I know of) follow here.

[webknjaz]

@pradyunsg you are right. I think I want it to be introduced along with the detailed explanation of the security considerations. Not sure if I'll be up for it right now — I need to recover from the today's drama. But feel free to remind me in a day or two...

[s-weigand]

@webknjaz If you want I can make a PR with a workflow to generate/automate the major version tags and you can add a detailed explanation of the security considerations. Sharded works means less work for all.
Also, good recovery 😄

[pradyunsg]

@s-weigand Please go ahead. I can't promise that @webknjaz would use it as is, but I'm certain that it'd be helpful to have it, even if it only serves as a starting platform! ^>^

[webknjaz]

Thanks, I'm honestly not sure what workflow I want but if you present me with options, I'll appreciate that. I recall that I looked at some automation in the past and didn't like something about it, can't remember what exactly, though.

[webknjaz]

Oh, I remember: haya14busa/action-update-semver that was submitted to another action I have doesn't support PEP440 versions, like .dev0 or .post0 suffixes that I like to use. I still feel that it's important to support it.

[s-weigand]

Oh, I remember: haya14busa/action-update-semver that was submitted to another action I have doesn't support PEP440 versions, like .dev0 or .post0 suffixes that I like to use. I still feel that it's important to support it.

Good to know, I will keep that in mind 😄
I guess .dev shouldn't trigger a major tag, while .post should.