search

WordPress / wordpress-importer

The WordPress Importer
https://wordpress.org/plugins/wordpress-importer/
GNU General Public License v2.0
78 stars 76 forks source link

Update version to 0.8.1 #150

Closed ouikhuan closed 1 year ago

ouikhuan commented 1 year ago

Based on the suggestion here it'll be better for us to use version 0.8.1 instead of 0.9

jrfnl commented 1 year ago

Side-note: version number bumps are normally only done just before a release.

ouikhuan commented 1 year ago

Side-note: version number bumps are normally only done just before a release.

Since WordPress 6.2 was released earlier last week, we thought it would be a good idea to test the plugin and update it to the latest version of WordPress, and it seems we need a version update to trigger the sync from git repo to SVN? Sorry, we are relatively new to the workflow, what's the best action to do here if we want to update plugins that's tested up the latest WordPress?

Also, we kept getting failure builds, is there any way we can fix this?

jrfnl commented 1 year ago

Side-note: version number bumps are normally only done just before a release.

Since WordPress 6.2 was released earlier last week, we thought it would be a good idea to test the plugin and update it to the latest version of WordPress, and it seems we need a version update to trigger the sync from git repo to SVN? Sorry, we are relatively new to the workflow, what's the best action to do here if we want to update plugins that's tested up the latest WordPress?

The sync to WP is only done on tags. To release a new version and sync with the WP SVN repo, a tag would need to be created. Updating the version number alone is not enough.

I think it might be a good idea to add a CONTRIBUTING.md and a release checklist to this repo with this kind of information. What do you think ?

If you need an example for what I mean by "release checklist" - here is one we use in the Requests project: https://github.com/WordPress/Requests/blob/develop/.github/release-checklist.md

Also, we kept getting failure builds, is there any way we can fix this?

That workflow only updates the readme and plugin assets, it doesn't do a release.

I haven't looked at that particular failure yet. IIRC @dd32 added that workflow, so he may know more.

Based on a quick look at the log, the problem is "Other files have been modified; changes not deployed". I would suggest checking in the repo of the action which is being used for the deploy if this has been reported before and what the recommendation to fix it was. If it hasn't been reported before, I would suggest adding a "on failure" debug step to the workflow which would show which other files have been modified (maybe using something like git status -b -v -u), so at least you can pinpoint the problem.

Also note that it looks like a develop version of the action runner is being used, so that could explain why things are unstable. I presume that was so chosen as develop, at the time of adding the workflow, contained some fix which was needed for this repo, but it should be checked if it is possible to use a stable version of the action runner instead.

Having said that, it would be good to prevent other workflows from getting into problems before they happen, which is what this list of PRs is all about: https://github.com/WordPress/wordpress-importer/pulls/jrfnl If I'm honest, those should be reviewed and merged before anything else gets merged as CI is currently not up to date, so PRs/merges are not checked thoroughly enough as things are without merging those PRs.

ouikhuan commented 1 year ago

I think it might be a good idea to add a CONTRIBUTING.md and a release checklist to this repo with this kind of information. What do you think ?

Agreed! I think a checklist will be very helpful!

Also note that it looks like a develop version of the action runner is being used, so that could explain why things are unstable.

The reason why we tried to use a develop version is because @zaerl from our team found a bug previously but it's not landed in the stable version. We initially suspected that this might be causing our problems, so we attempted to switch to the develop branch to see if the build would succeed. However, even after making the switch, we were still unable to resolve the issue. If that's not the issue, maybe we can switch it back to the stable version?

@dd32 Could you suggest what's the best way moving forward? If the build is failure only because we modified the readme file and other files in the same PR, then I guess it should be fine to ignore it?

Having said that, it would be good to prevent other workflows from getting into problems before they happen, which is what this list of PRs is all about: https://github.com/WordPress/wordpress-importer/pulls/jrfnl

Having checks to prevent problems from happening will definitely help IMHO