Thank you for the further insights folks. The Confluence engineering team are reviewing the above and we’ll respond here once we have some updates.
@klaussner & @bobbergman1 regarding your comments:
If Atlassian follows their policy explained in the latest RFC comment, this feature gap alone should prevent a deprecation.
I too am confused by this. There are known gaps today, such as CONFCLOUD-76343 and CONFCLOUD-76344. Does that mean that the deprecation of the
wiki/rest/api/spaceendpoint is extended until delivery+6 months?
Apologies, the language we’ve used here is a little confusing—I’m making a note to be more careful with our terminology. To avoid ambiguity in this context I’m going to use “Deprecated” in the traditional sense of meaning “Marked for removal at some future date”, and “Removed from service” to mean the API is no longer accessible.
The intent behind this segment on the final comment on the RFC:
“If there are any gaps for a specific API endpoint, rest assured that we will only deprecate that endpoint six months after achieving parity for that endpoint.”
…is that specific end-points in the v1 API will not be removed from service until 6 months after the v2 API has a suitable replacement for that end-point.
It seem reasonable that that would apply to both the cases you mentioned (/rest/api/content/{id}?expand=metadata.properties.xyz and /rest/api/space) but I will confirm this with engineering.
I believe the intent behind the update was to add an additional month to the deprecation schedule for all deprecated v1 APIs as a gesture of good will, but also signal that we’re willing to extend that further for the individual APIs which do not yet have suitable replacements (I also agree we need a better public-facing mechanism for tracking this).