Say a given subsystem defines the following schemas:

VERSION_1_0_DEFAULT
VERSION_2_0_DEFAULT
VERSION_2_0_COMMUNITY

The PersistentResourceXMLDescription logic might contain the following to conditionally register some resource/attribute for the community:2.0 schema only:

if (this.since(VERSION_2_0_COMMUNITY)) {
  // ...
}

Parser logic like this should never have to change until the associated feature is "promoted".

If the next release adds a new community feature, our next schema becomes VERSION_3_0_COMMUNITY, and our logic still works. However, if the next release added a new default feature, we would need to add 2 new schemas (1 containing VERSION_2_0_DEFAULT + the new default feature, and 1 containing VERSION_2_0_COMMUNITY + the new default feature) with the following namespaces:

VERSION_3_0_COMMUNITY
VERSION_3_0_DEFAULT

However, while VERSION_3_0_COMMUNITY.since(VERSION_2_0_COMMUNITY) returns true, as it should, we now have the case that VERSION_3_0_DEFAULT.since(VERSION_2_0_COMMUNITY) will also return true (since() only compares versions). This is not ideal. We should not have to revisit previous conditions in order to evolve the schema in an manner unrelated to the original change.

To handle this nicely, the since(...) method should only return true if the version comparison returns true and the stability level of the specified namespace is enabled by the stability level of the PersistentResourceXMLDescription's namespace, such that VERSION_3_0_DEFAULT.since(VERSION_2_0_COMMUNITY) returns false.

Let's now say that, in the next release, our original community feature gets promoted to default stability, so that we have a new schema: VERSION_4_0_DEFAULT

We would then update our original condition to use:

if (this.since(VERSION_2_0_COMMUNITY) || this.since(VERSION_4_0_DEFAULT) {
  // ...
}

This makes it clear, not just when the feature originated, but also when the feature was promoted.