Open spier opened 1 year ago
@jcfr I feel like my descriptions here are a bit over the top :) Would still be curious to get your input on how to best release GHAs, mostly out of curiosity.
Thanks for the detailed review :pray:
re: update to node16
re: naming convention for branches and tags
Until support for node12 is officially removed, I suggest we:
v1.x
as tag and not a branchreleases/v1
(from which v1
, v1.x
and specific v1.x.y
tags will be updated/created). This is branch where we will backport fixes.v1.x
and v1
While addressing https://github.com/swinton/screenshot-website/issues/80 I suggest we the create the tags v2
and v2.x.y
. There is no need for releases/v2
because the v2 will be created from main
The approach you suggest sounds like it will work as well. It does seem to introduce more maintenance overhead though, which I was trying to prevent. I mean maintenance overhead as in "more things to remember".
Some considerations below.
Maybe one question we need to decide on is:
When do we want to end of life (EOL) v1.x?
Was your thought that when node12 is officially removed from GHA, this is when v1.x
will stop working?
It may be a long time until that happens though, I would assume.
Also how many users are actually affected by this? i.e. how many users does this GHA have?
A public search on GitHub shows 85 files containing uses: swinton/screenshot-website@v1.x
. Of course we don't know how many more private repos are using the workflow.
And lastly, your description sounds like you favor tags over actual releases (In the GitHub sense). What is the advantage? I only know that with releases you can add more context about what was released, who contributed, etc in the release notes.
I was wondering how to best create stable releases of this GitHub Action going forward?
Given that development on this project is just picking up speed again, this may not be the most important topic right now. Still I wanted to put it in writing, so that we don't forget about it.
Worthwhile goals would be
Now I noticed that the documentation currently suggest to use the
v1.x
string:That might be a bit misleading, at least it was for me. Based on the
v1.x
string I assumed:v1
major version. However this does not automatically work but only if for every new release thev1.x
branch is updated as well. This means extra burden for the maintainers.Suggested Release Strategy
I don't know many users this GHA has, so the level of effort that should be put into this is certainly up for debate.
FYI I am basing my assumptions on how GHA version works on ^1 and ^2.
Now how could we version/release this GHA going forward:
v1.x
working for a while (e.g. upgrade to node16 plus the actions/core upgrades that are already done). then update thev1.x
branch with these fixes, and create new packaged releases in parallel as desired (e.g.v1.1.0
andv1.2.0
)v1.x
branch (to save the maintainers extra burden)v1
instead ofv1.x
allowing new users to automatically benefit from new releases of the 1-major versionAlternative
An alternative to this might be to not update the
v1.x
at all, so that it will break at some point (not sure when that will be).That might motivate users of this GHA to read the documentation again, and notice the new releases. For this to work we would have to make it super obvious for them which change they have to make to get the latest version.
Thoughts?