Provide option to pick version from Stable tag in README.TXT

[richard-muvirimi]

Description of the Change

Not all WordPress plugins make use of Github release tags (yes, release tags can be created through a workflow), which adds an extra unnecessary step. Having an option to select the method to obtain the release tag would to a certain extent allow a degree of freedom to switch between tags and use of preferred release method whilst directly controlling the version released to WordPress.

Partially addresses #85

Alternate Designs

Alternatively one can manually create a release (maybe use a workflow) to be picked by this workflow, but this adds another layer and steps to the release process.

Another option though not documented would be to set the version environment variable the same way SVN_USERNAME and SVN_PASSWORD is set using a bash script to extract the version number

Possible Drawbacks

Those relying on tags would wish they had this feature earlier ;), on a more serious note, I could not think of one but I will make it known that whilst looking for a workflow to push to WordPress (had a local script before Gist extract WordPress Plugin) I was instantly deterred by the forced use of release tags.

Verification Process

I copied a README.TXT file into the directory and placed the stable tag with different capitalizations in random places in the document. then in a different dot sh file, I extracted and echoed the first version number which is the one read by WordPress.

VERSION=$(find . -iname "README.TXT" -exec grep -oiP -m 1 'stable\s+tag\s*:\s\K.*' {} \;)
echo ${VERSION#v}

Checklist:

• I have read the CONTRIBUTING document.
• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have added tests to cover my change.
• All new and existing tests passed.

Changelog Entry

Credits

Props #85 felt close to the problem this PR addresses

[dinhtungdu]

@richard-muvirimi Thanks for the PR!

As far as I understand this PR, this action shouldn't be run on tags anymore. So when should it run (or how the plugin is released)? Here are my thoughts and observation, please correct me if I'm wrong.

• I'm thinking about deploying on publishing a new GH release, which also requires creating a new tag.
• I also think about running this action on pushes to branches, if it's the case, then how we can prevent deploying the same version?
• If we still run this action with the new flag introduced in this PR on tags, I don't see why don't we just use tags and read the version from the tag. It's hard to manage if the w.org and GH versions are different.

While we can totally do this, I'm wondering, should we do this? IMHO, using tags is a manageable way to do releases. Up for debate.

Edit: As you mentioned in another PR, we can already set the custom version using GitHub environment variables. See https://github.com/richard-muvirimi/Woo-Custom-Gateway/blob/production/.github/workflows/deploy.yml.

I may be biased so I'm tagging @jeffpaul and @peterwilsoncc here for more opinions on this.

[richard-muvirimi]

Just to clarify, picking the version from release tags and from the README.txt will both be supported, it will be the choice of the user to use either. Below is my attempt to answer all your questions

As far as I understand this PR, this action shouldn't be run on tags anymore. So when should it run (or how the plugin is released)? Here are my thoughts and observation, please correct me if I'm wrong.

As outright stated above, both would be supported. Room for maneuverability is always good especially if designing for different setups. For most users (plugin developers), GitHub tags are one of the features Github provides, that they don't use. One already has the plugin on the WordPress Store, so why the extra burden to create a Github tag if you are not going to be directing traffic to Github? Tags work if you have a number of contributors working on the project, but if you are solo, you just want to push the plugin to WordPress.

I also think about running this action on pushes to branches, if it's the case, then how we can prevent deploying the same version?

The way this would work is if a tag is not changed, it will just copy the files to an existing tag directory, else it will create a new tag directory. This would be useful for example if one needs to update the supports WordPress, Woocommerce, update dependencies or change functionality in an already released tag.

People download and use old versions of plugins & themes, and maybe after fixing a security vulnerability, one may want to push to an older version which is not possible with tags.

If we still run this action with the new flag introduced in this PR on tags, I don't see why don't we just use tags and read the version from the tag. It's hard to manage if the w.org and GH versions are different.

This PR provides an OPTION for those who don't want to use release tags (though that option would be there). It might seem like the only way (Github Release Tags) but some have been pushing plugins without tags for quite some time and changing their workflows just to meet the requirements of this action would be a bit too demanding.

As you mentioned in another PR, we can already set the custom version using GitHub environment variables.

Modifying Github environment variables are more of a hack and require good knowledge of the bash language. Github might one day prevent modifying the environment from outside action context, as they currently do with destructive file actions. Having this built-in would be future-proof whilst also catering to the different ways we develop and deploy plugins.

As a solo WordPress plugin developer, zipping, and creating a version tag might be demanding (yes can be assigned a workflow) when I never intend to have traffic on the Plugin's Github page

Examples, where tags are minimally used, would be

1. Really simple SSL
2. Duplicate Page
3. Hello Dolly

[dinhtungdu]

As far as I understand this PR, this action shouldn't be run on tags anymore. So when should it run (or how the plugin is released)? Here are my thoughts and observation, please correct me if I'm wrong.

As outright stated above, both would be supported. Room for maneuverability is always good especially if designing for different setups.

I was mistyping this question. I meant that this action shouldn't be run on tags if version-stable-tag is set to true. Just want to clarify.

For most users (plugin developers), GitHub tags are one of the features Github provides, that they don't use.

Do you have any research or statistics about the number of plugins developers who don't use GitHub tag? I believe that there are many developers who don't use tags, but I'm quite surprised if most of them don't.

As you mentioned in another PR, we can already set the custom version using GitHub environment variables.

Modifying Github environment variables are more of a hack and require good knowledge of the bash language.

I agree.

This would be useful for example if one needs to update the supports WordPress, Woocommerce, update dependencies or change functionality in an already released tag.

I'm against doing this. If we change functionality to an existing release, how can users who updated to that release get the new updates?

Github might one day prevent modifying the environment from outside action context, as they currently do with destructive file actions.

Can you share some references on this? I'm curious about their direction too.

As I mention above, I acknowledge that we now have two options to deploy the plugin. And I'm not against adding more options to this action (Please don't get me wrong 😄). What I'm considering here is how should the new option would be used and what is the confusion that new option may create. I agree that extracting the version from the readme file is handy, but I'm not very clear about the workflow with that option, which I raised above.

[peterwilsoncc]

I agree with @dinhtungdu that this change out of scope for this action.

I consider this action's purpose as to keep a GitHub repository and the WordPress.org repository in sync, and that includes tags or releases.

Changing how the version is calculated risks breaking some of the repositories using the action (over 1,600) if their process is to merge readme.txt updates, complete some other steps (such as quality assurance) and then tag the new release.

[richard-muvirimi]

@peterwilsoncc I think you have misunderstood what this PR brings. It adds an option where a user would be free to choose one of three options i.e

1. Tags
2. README.txt
3. Set version manually

and existing workflows will continue to work the same.

A quick perusal through the added code changes will make this clear.

It's not everyone that wants to work with Github tags (I currently do not have the statistics), and there is no harm in following a WordPress standard to set the version number.

For all i know this is just a workflow action which should not care much about how you provide your content, and just be a means to complete a certain task.

[richard-muvirimi]

As I mention above, I acknowledge that we now have two options to deploy the plugin. And I'm not against adding more options to this action (Please don't get me wrong 😄). What I'm considering here is how should the new option would be used and what is the confusion that new option may create. I agree that extracting the version from the readme file is handy, but I'm not very clear about the workflow with that option, which I raised above.

@dinhtungdu For this workflow, there would be a production branch and a development branch. Once one pushes to the production depending on their setup a workflow would be triggered. This is much like the rsync actions, which will deploy code to remote servers when the right conditions for a workflow are met, which might be commit message containing, branch, day etc

[richard-muvirimi]

@dinhtungdu @peterwilsoncc i might have come off as demanding in my previous comments, but the real purpose for my PR is, i use a different workflow, that is not tag based. I know there are others that might have the same workflow and might not be easy to understand especially if you have not used such. Instead of creating a completely new action, I felt it better to contribute to an existing one but if my contributions are not well received, you may close this PR. All changes brought by this PR, are 100% compatible with existing workflows as they are opt-in based.