mavschema.xsd: add superseded tag

[hamishwillee]

This adds a superseded tag. Once this is in. my intent is to divide the existing deprecated tags into those that are actually deprecated by the standard (and we hope to remove) and those that are just superseded by a new message, command, enum that we hope one day everyone will upgrade too.

The difference being that superseded is as much a hint to autopilots as users that there is something that might we worth upgrading to.

This is a precondition to any kind of release process.

NOTE. I thought about adding deprecated, wip, superseded as possibilities for field values and param values. However I'm not sure this is useful. I.e. In one way it is - you can indicate that things are new - or not intended to be used with clear tagging. But you can't actually "remove" a field that is in common.xml if you add "deprecated" and you can add WIP but it's public ... so not sure. Assuming not for now.

[hamishwillee]

FYI, just a reorder for wip and deprecate, which is what makes this a bit messier. Sorry.

[hamishwillee]

@auturgy @peterbarker Can we get some movement on this? ONly a year and a half late ....

Plan is to move current deprecated to superseded unless they are "really" deprecated. I think that is a little less confusing.

[peterbarker]

@hamishwillee could you provide some concrete examples on where this would be applied, please?

Is this part of a life-cycle of some description? So do things move from superseded to deprecated, for example?

Do we outline a life-cycle anywhere? That would be wip -> -> superseded -> deprecated -> removed, I think with this current proposal?

[hamishwillee]

Hi @peterbarker

The intent here is to reduce confusion in the naming so that we can move towards a lifecycle. Currently we use the term deprecated to mean both:

• superseded: there is a newer way of doing this same thing we'd like flight stacks to implement, and users to use instead of the older alternative. Does not mean that it is implemented or the old version is not in use.
• deprecated: this is something you should not use because it is planned for removal.

So yes, the intent is to have a lifecycle. We don't outline the lifecycle because it is a mess.

Yes, my thinking was: wip -> "active" -> superseded -> deprecated -> removed.

• Though something might be deprecated without being superseded.

It isn't perfect, because it doesn't help a user know whether anything can be used - i.e. I come to superseded, navigate to the new API and discover it isn't implemented anywhere. It does however help us know what we'd like flight stacks to be moving towards and deprecating.

Does that make sense?

[hamishwillee]

could you provide some concrete examples on where this would be applied, please?

Initially I would move everything that is deprecated to superseded in one PR. Then we would discuss which are really deprecated.

I'd be doing some testing and propose.

But there is no point working out what can really be deprecated if there is no way of me marking it.