Remove unused (and generally wrong) <tag> markup from Update module test XML fixtures

perl -n -i.bak -e 'print unless m/<tag>/' *.xml
;)

All tests passed, so crossing that off from remaining tasks.

Also, calling this a sub-task of #3110917: [meta] Fix update XML fixtures bad data

Thanks,
-Derek

Re: #4:

A) Yes, both feeds have the value. They have the same values (the git tags). Not sure what you mean by "although with different values". I can't spot any examples of that.

B)

In my opinion our test fixtures should be as close as possible to what drupal.org's XML as possible.

Then there are a bunch of other values that our test fixtures are missing, like the entire <files> section for each release, etc. IMHO, our test fixtures should be realistic, but only include enough info for the tests to do their job. There's 0 code in update module that uses this, neither the code nor the tests, so this is entirely noise:

% grep -i -r 'tag' --exclude '*.xml' core/modules/update
core/modules/update/migrations/update_settings.yml:migration_tags:
core/modules/update/update.module: *   'Insecure' release type tag in update XML provided by Drupal.org to
core/modules/update/update.module:  trigger_error("_update_equivalent_security_releases() was a temporary fix and will be removed before 9.0.0. Use the 'Insecure' release type tag in update XML provided by Drupal.org to determine if releases are insecure.", E_USER_DEPRECATED);
core/modules/update/update.services.yml:    tags:
core/modules/update/update.services.yml:    tags:

In other core test fixtures (e.g. default views for tests) we tend to keep the default view config as small as possible for each test, instead of having full views exports for every single test view. This generally makes it easier to understand, since you don't have to read through 2000 lines of views config for every test view.

C)

If there is no use for this element it should be removed from the drupal.org XML first.

Update module isn't the only possible consumer of this API. Just because update.module nor our tests reference these values doesn't mean d.o should remove them from the feed. Added note about this to the summary.

D)

It is very unlikely but having it in our test fixtures would stop us from doing something like ...

That's quite a stretch. ;)

If you want to keep <tag> in the fixtures, then we have a very large task to actually go through and give them accurate values. That's going to take hours, and we have much more important fish to fry. Instead, we could agree that this is completely meaningless garbage in our fixtures that's accumulated over the years from copy/paste that should be purged by script. ;)

Thanks,
-Derek

Refreshing this, and adding a 8.8.x version. Interdiff is pointless.

@tedbow Re: #7: It's not clear if you've read #5. I don't want to repeat all those reasons here. Would you be willing to respond to the specific points in #5?

Thanks,
-Derek

Re-generated patches now that #3121020: Move Update Manager XML test fixtures into a fixtures/release-history directory landed. The main patch applies cleanly to 9.1.x through 8.9.x. Separate patch needed for 8.8.x.

Yay, thanks @quietone!

I now realize that #3110917: [meta] Fix update XML fixtures bad data is basically duplicate with #1478294: Update manager XML test fixtures contain D7 links to D8 releases, although #3110917 has a better scope at the moment.

I totally agree we (probably I) should document what parts of these feeds the update manager actually uses. I'm not sure if update.api.php is the best spot, since that's usually where we document the external API a given module provides (e.g. the hooks it invokes that other modules can use), right? Do we put internal API docs in there, too? Anyway, split that out to #3203359: Document what elements in the release history XML feeds the Update manager uses. Comments welcome there for where to put the docs.

Also good question on https://www.drupal.org/drupalorg/docs/apis/update-status-xml -- I'm 95% sure that's complete (all thanks to @drumm and @tedbow), but it's worth a review to be sure.

Thanks again!
-Derek