Clean up tag branches

[johnpbloch]

This issue is to track the efforts to clean up all of the tag-* branches as mentioned by @seldaek in #18.

• [x] Merge tags into release branches
• [x] Delete tag branches
• [x] Update build repo to always build tags in release branches

[johnpbloch]

Responding to @Seldaek's comment here (quoted below):

@johnpbloch thanks! That helps already a bit, but what would be even better is if you can get rid of the "build" branches https://github.com/johnpbloch/wordpress-core/branches all these named tag-*. I suspect they don't really need to be pushed ever.

tl;dr: I think I have a good plan to move forward, delete all tag branches, and not create new ones in the future. 🎉 🎊

First, why it is the way it is right now:

The reason I used the current layout for the repository was to allow building multiple tagged releases at the same time. Using separate branches for each tag avoided the possibility of merge conflicts. So they branch off an initial empty commit, dump the tagged release into the repo, add composer.json, commit, and tag. That's the release. But I also don't want to have these tag branches adding a bunch of dev releases to the repo. So I followed the documented method of hiding a branch from composer: delete composer.json, commit. In practice, I don't do concurrent release builds any more, so the branching model itself didn't make sense any more, but I kept the tag branch scheme rather than moving releases into the dev branch for their major version because the official packaged releases from WordPress upstream usually lag behind the VCS releases by a few hours at least. That would have meant needing to rebuild the branch after each tag build. Not a great reason, but hopefully this explains why the repo looks the way it does.

The solution:

Clearly, the scale of the number of releases we're dealing with here makes that a bad solution. So, for all future releases, I'll be building tags onto the dev branch for their major version. After tagging the release, I'll just revert the commit to reset the HEAD of the dev branch to the previous state. That way, packagist picks up the tag, and the correct state of the dev branch.

For all existing tag branches, I'll be merging them all into the dev branch so that the commit hashes and tags all stay the same and nobody's installation gets hosed. Nobody needs another one of these days. After the tag branches have all been merged into their respective dev branches, I'll rebuild each dev branch to the appropriate state and delete the tag branches.

[johnpbloch]

Ok, build script is updated, the bot is back online. Everything got built correctly and subsequent updates did not erroneously push without updates to the remote repo. The tag branches are all gone, tags are moved to and built on the version branches.

@seldaek please let me know if there's anything else i should do to make the package play better with packagist.

[Seldaek]

Looks good now I think, thanks. For the record when building a tag, you don't need to push the related branch, you can create a branch, create a tag from it, delete the branch and then push tags and that'll work fine. No need for this commit then revert commit thingy you described above IMO.