docs: merge deprecated table

[teleivo]

I would like us to document deprecated features in one place. In tracker we list all deprecations and removals in the release notes. Can we thus just link to those sections from this page?

I would merge the two tables so it's easier to see when it has been deprecated, is planned for removal and is going to be removed.

Do we have an official release calendar we can link to? At least for us devs to get the dates right. Or to only mention the release version as the dates are never set in stone. At least not when we write these docs.

• if someone could clearly state who the audience is for this doc? when/how often are they consulting it? do we publish this somewhere?

[Philip-Larsen-Donnelly]

I like the new format (single table) but we seem to have lost a little verbosity?

The audience has mostly been internal until now. It is useful to follow up to make sure we deprecate features in a timely manner, and we have used it as part of the release process to ensure we are communicating key deprecations.

Under the "Upgrades initiative" we have recently been discussing whether we should publish this more formally in a way that implementations can refer to it as part of their upgrade planning/preparation. (We currently refer to it briefly in the draft upgrade documentation that is being developed).

Note. We state that "a feature is removed after it has been deprecated in all three of the last maintained versions", so should think carefully about deprecating in v42 for removal in v43 (i.e. the most recent tracker entries).

[teleivo]

I like the new format (single table) but we seem to have lost a little verbosity?

I can revert that "summary" 😅

The audience has mostly been internal until now. It is useful to follow up to make sure we deprecate features in a timely manner, and we have used it as part of the release process to ensure we are communicating key deprecations.

From the perspective of a dev: don't you worry, I want to get rid of code, I won't forget 😂

Under the "Upgrades initiative" we have recently been discussing whether we should publish this more formally in a way that implementations can refer to it as part of their upgrade planning/preparation. (We currently refer to it briefly in the draft upgrade documentation that is being developed).

In terms of external communication: we already have the https://github.com/dhis2/dhis2-releases/tree/master/releases markdown files. In tracker we fill them in as soon as we do something so they can always be followed. Granted there is no 43.md yet but that is something we can adopt (having the next 2 to be released versions release notes ready). So we could put the removal in there even before doing it.

A public release calendar like https://nodejs.org/en/about/previous-releases could then link to the versions markdown. We can settle on a common structure for https://github.com/dhis2/dhis2-releases/blob/master/releases/2.42/README.md that is easy for people to navigate. Group by breaking, deprecated and products in each vs products and breaking, deprecated, ...