Removed support for version = '1.0' on VOTable

[marcellonascif]

Description

This pull request removes support for '1.0' on VOTableFile__init__().

I basically removed a condition with version '1.0' specified and now '1.0' is treated like other versions which are not in _version_namespace_map dictionary. It means that now '1.0' raises a ValueError instead of a DeprecationWarning.

I also changed the test file to check if '1.0' is raising a ValueError as expected. It has passed the tests.

Fixes #11669

[github-actions]

Thank you for your contribution to Astropy! 🌌 This checklist is meant to remind the package maintainers who will review this pull request of some common things to look for.

• Do the proposed changes actually accomplish desired goals?
• Do the proposed changes follow the Astropy coding guidelines?
• Are tests added/updated as required? If so, do they follow the Astropy testing guidelines?
• Are docs added/updated as required? If so, do they follow the Astropy documentation guidelines?
• Is rebase and/or squash necessary? If so, please provide the author with appropriate instructions. Also see instructions for rebase and squash.
• Did the CI pass? If no, are the failures related? If you need to run daily and weekly cron jobs as part of the PR, please apply the "Extra CI" label. Codestyle issues can be fixed by the bot.
• Is a change log needed? If yes, did the change log check pass? If no, add the "no-changelog-entry-needed" label. If this is a manual backport, use the "skip-changelog-checks" label unless special changelog handling is necessary.
• Is this a big PR that makes a "What's new?" entry worthwhile and if so, is (1) a "what's new" entry included in this PR and (2) the "whatsnew-needed" label applied?
• Is a milestone set? Milestone must be set but we cannot check for it on Actions; do not let the green checkmark fool you.
• At the time of adding the milestone, if the milestone set requires a backport to release branch(es), apply the appropriate "backport-X.Y.x" label(s) before merge.

[pllim]

Thanks! Still needs a change log.

While the diff LGTM, I would like PyVO community to chime in, in case someone still needs 1.0 parsing for whatever reason.

[github-actions]

Welcome to Astropy 👋 and congratulations on your first pull request! 🎉

A project member will respond to you as soon as possible; in the meantime, please have a look over the Checklist for Contributed Code and make sure you've addressed as many of the questions there as possible.

If you feel that this pull request has not been responded to in a timely manner, please send a message directly to the development mailing list. If the issue is urgent or sensitive in nature (e.g., a security vulnerability) please send an e-mail directly to the private e-mail feedback@astropy.org.

[marcellonascif]

Hey @pllim. I'll do it rn. I just need to add the file in docs/changes/io.votable explaning what I did, right?
Do I have to worry about these checks failing? Just checking.

[pllim]

For change log, please see https://github.com/astropy/astropy/blob/main/docs/changes/README.rst

For pre-commit, see https://docs.astropy.org/en/latest/development/workflow/maintainer_workflow.html#pre-commit-bot

The change log check failure will go away once you added a change log unless you did it wrong.

I wouldn't worry about codecov until the entire test suite has finished running.

Hope this helps!

[marcellonascif]

pre-commit.ci autofix

[marcellonascif]

Those two problems you pointed were fixed. Thanks for you patience!

[tomdonaldson]

I'm fine with these changes. It is basically turning what was deprecated for quite some time into an error.

I note, however, that both the deprecation and the new error are more limited in scope than they sound. Both only happen when version="1.0" is specified in the constructor. What remains unchanged is that the parser will still parse a version 1.0 VOTable (with warnings about the version when using validate() or volint). If such a table is then written back out with to_xml() (both before and after this change), it will not be valid due to the absence of the <DEFINITIONS> element which was only required in v1.0 VOTables.

I actually think this is a reasonable balance, and that the issue #11669 should have been written with that more limited scope. It's OK to still accept a version 1.0 table, but still strongly encourage the Astropy coder not to create one deliberately.

[tomdonaldson]

And thanks @marcellonascif for working on this. With astropy 6.0 coming out, this is a good time to remove that old deprecation.

[tomdonaldson]

This looks good to me.

[pllim]

Thank you, all!

[marcellonascif]

Thank YOU guys! I'm really happy I could fix my first issue. Thanks for your patience while helping me.