Make beta & RC releases available in Github

[malthert]

It would be awesome if WP beta & RC releases/tags would also be available on ​https://github.com/WordPress/WordPress

[georgestephanis]

My first inclination is that this may be more of an issue to raise on Meta Trac -- ​https://meta.trac.wordpress.org/ -- which tends to focus on the tooling /around/ the core software. But it also gets fewer eyes on it than here so 🤷🏽‍♂️

[Clorith]

As @georgestephanis mentioned, this is more a meta ask, but I'm curious as to what problem this would solve that grabbing the latest master build wouldn't cover?

​https://meta.trac.wordpress.org/ticket/3245 looks like it might provide some leverage in the direction you are seeking, although not directly github related, it does investigate the idea of providing different update channels and is a likely starting point.

[malthert]

Latest master may be anything in between (= reporting bugs is harder, since the issue might be due to an issue created after e.g. Beta 1 was released, which is what I am currently testing) releases.

Additionally, WP may have any "build" tasks that run for a release (beta, RC,...) which may not be present in master.

[SergeyBiryukov]

#51671 was marked as a duplicate.

[om4csaba]

Please consider adding pre-release tags to the source repos as well.

• ​git://develop.git.wordpress.org/
• ​https://github.com/WordPress/wordpress-develop

Thank you

[SergeyBiryukov]

#53499 was marked as a duplicate.

[ocean90]

#54454 was marked as a duplicate.

[dd32]

Commenting to move ​meta ticket back to core :)

This is entirely up to the core team at this point in time - If you wish to make it available via tags on the *.git.wordpress.org repo's and ultimately as tags on ​https://github.com/wordpress/wordpress/ & ​https://github.com/wordpress/wordpress-develop/ then it simply needs to be tagged as such within ​https://develop.svn.wordpress.org/ (which will sync all the way through hopefully, but some build scripts might need updating).

Unfortunately integrating with GitHub Releases is probably not possible at this time, due to the release processes being tied to SVN rather than Git.

I don't personally see a major benefit to tagging pre-releases, but I can see why some may want it. It might also make it easier to compare diffs/find commits between Betas/RCs I guess.

[om4csaba]

@dd32 

I don't personally see a major benefit to tagging pre-releases, but I can see why some may want it. It might also make it easier to compare diffs/find commits between Betas/RCs I guess.

As a plugin developer, we are constantly running tests in CI against the upcoming releases. Both for the tagged pre-releases and the latest commit in the "main" (trunk) branch.

Because the whole system is git-based, we clone every dependency in the CI and run the test. Currently, I manually search for the commit hash for pre-releases, but it will be way easier for us if the pre-release tags are in there.

[dd32]

Replying to om4csaba:

As a plugin developer, we are constantly running tests in CI against the upcoming releases. Both for the tagged pre-releases and the latest commit in the "main" (trunk) branch.

Because the whole system is git-based, we clone every dependency in the CI and run the test. Currently, I manually search for the commit hash for pre-releases, but it will be way easier for us if the pre-release tags are in there.

For automated testing, testing against trunk would be better IMHO, knowing it's broken in Beta1 isn't super useful IMHO if it was fixed the next day in trunk. Knowing that your plugin broke with trunk a month before Beta is also hugely beneficial to the core community, as bugs can be located faster, and realistically plugins shouldn't break that often. Yes, it means it's more likely to fail incorrectly, but that's a small price to pay.

However, I would also suggest that using GIT/SVN to fetch pre-release releases is probably not ideal (although I understand part of your current workflow), I would suggest something like wp core download --version=beta would be better (unfortunately wp-cli only seems to support stable/nightlies right now, not beta/rc). But you could also do wp core download https://wordpress.org/wordpress-5.8.2-RC1.zip, or just replace your git clone with a curl $url | unzip command.

[malthert]

@om4csaba this is exactly our use case too.

Replying to dd32:

For automated testing, testing against trunk would be better IMHO, knowing it's broken in Beta1 isn't super useful IMHO if it was fixed the next day in trunk.

Would be better, and this is the way we did it before. Unfortunately, if a new bug is added in trunk, it means it takes more than double the time to identify the source of the bug: we suddenly have changed 2 things (our code we test in CI) and the commits in WP core - so we have to debug double the things, to check whether the bug came from our changes or from the changes in trunk.
If you only have one/few branches/plugins you test, that might not be an issue, but when you have to check 20 plugins and have multiple developers, we are suddenly wasting a lot of time.

However, I would also suggest that using GIT/SVN to fetch pre-release releases is probably not ideal (although I understand part of your current workflow), I would suggest something like wp core download --version=beta would be better (unfortunately wp-cli only seems to support stable/nightlies right now, not beta/rc). But you could also do wp core download https://wordpress.org/wordpress-5.8.2-RC1.zip, or just replace your git clone with a curl $url | unzip command.

That's basically what I do atm. The issue here is that I have to manually look up what is the latest Beta/RC first and then download that (sounds ridiculous I know...)

Advantage of git tags would be that I can automatically get the latest beta/rc/release to use in CI.
Instead of having a calendar reminder every week to download the latest WP beta/RC in the weeks leading up to a new WP release, it could be fully automated with git tags.
Saving me, and probably everybody else with CI, 2 days a year.

[malthert]

@priethor as release coordinator for 6.0, could you make this happen (starting with Beta 1 of 6.0)?

I guess that there are some internal docs (since releases get tagged just fine), so we'd just need to amend them - to ensure that beta/RC releases are tagged the same way that releases are tagged.
If these guidelines are public and open to contribution I'd do that myself, I just couldn't find anything anywhere.