featureCounts: apply IUC tool_xml formatting conventions

[richard-burhans]

Applies the IUC tool_xml formatting conventions to featureCounts. Reworked after the earlier review: this revision is formatting-only and deliberately drops the things raised on the first pass.

What changed:

• normalize <param> attribute order to the best-practices coding-style order (name, argument, type, min/max, value, ...), and likewise value/ftype/dbkey order in the test params
• self-close empty elements

What this revision intentionally does NOT do, per the earlier feedback:

• no profile change (stays 25.0)
• no blank lines between top-level sections
• no XML declaration added
• command-line quoting is limited to input and output files only (text params left alone)

The only non-formatting change is bumping @VERSION_SUFFIX@ 1 → 2, which planemo shed_lint requires for a changed, already-published tool to republish. The command line is unchanged in behavior.

[bernt-matthias]

I would suggest to keep the profile and merge without bump.

In the end none of the changes is really necessary. Also we do not have a normal form for the order of attributes.

[mvdbeek]

I would suggest to keep the profile and merge without bump.

that makes publishing bug fixes impossible / hard. the profile version allows opting into newer behavior, but there isn't even a documented change after 25.1, and even the 25.1 behavior doesn't apply here.

[richard-burhans]

I would suggest to keep the profile and merge without bump.

In the end none of the changes is really necessary. Also we do not have a normal form for the order of attributes.

The order was taken from the best practices documentation: https://galaxy-iuc-standards.readthedocs.io/en/latest/best_practices/tool_xml.html#coding-style

[richard-burhans]

I would suggest to keep the profile and merge without bump.
In the end none of the changes is really necessary. Also we do not have a normal form for the order of attributes.

The order was taken from the best practices documentation: https://galaxy-iuc-standards.readthedocs.io/en/latest/best_practices/tool_xml.html#coding-style

I think I was too aggressive here, the documentation states "variables for text parameters, input and output files". I'll make sure I'm only quoting what the documentation mentions.

[mvdbeek]

The order was taken from the best practices documentation: https://galaxy-iuc-standards.readthedocs.io/en/latest/best_practices/tool_xml.html#coding-style

one year older would be 25.0, which is still insanely strict. certainly when we're only causing problems and get no benefit whatsoever.

[mvdbeek]

xref galaxy-iuc/standards#62 (comment)

[richard-burhans]

The order was taken from the best practices documentation: https://galaxy-iuc-standards.readthedocs.io/en/latest/best_practices/tool_xml.html#coding-style

one year older would be 25.0, which is still insanely strict. certainly when we're only causing problems and get no benefit whatsoever.

Across the five major servers (org, eu, org.au, fr, ca) 25.1 is the oldest version running.

[mvdbeek]

We are an open community with plenty of servers we don't even know about, and you can search through the IUC issues to find out that people are indeed facing problems with this: https://github.com/galaxyproject/tools-iuc/issues?q=is%3Aissue%20state%3Aclosed%20profile. We've added the profile version feature so that we can roll out better defaults while maintaining reproducible behavior for older tools. Sticking to one interpretation of a document in a way that wasn't even ever intended (26.1 isn't released yet) and forcing people to upgrade their instance is not what we should do. And I repeat, there's nothing we actually gain from doing this except for alienating our user base.

[richard-burhans]

We are an open community with plenty of servers we don't even know about, and you can search through the IUC issues to find out that people are indeed facing problems with this: https://github.com/galaxyproject/tools-iuc/issues?q=is%3Aissue%20state%3Aclosed%20profile. We've added the profile version feature so that we can roll out better defaults while maintaining reproducible behavior for older tools. Sticking to one interpretation of a document in a way that wasn't even ever intended (26.1 isn't released yet) and forcing people to upgrade their instance is not what we should do. And I repeat, there's nothing we actually gain from doing this except for alienating our user base.

This is why I changed the way my code worked after your first comment.