The deprecation info API is used during upgrades to help users better understand the changes that are necessary before they upgrade. To help present this information each entry exposes an HTTP link for additional documentation. These HTTP links are embedded in the source code and like all remote links have the potential to be broken.
We recently switched to using shortened links which will allow us to better mitigate any broken links. However, we should also include some CI validation that these links are still good.
Ideally, with both shortened URLs and validation we could also consider opening the door to allow exceptions, deprecation logs, server logs, etc. to also embed HTTP links if it makes sense.
I assume we would need to :
- externalize all of the HTTP links to a resource file
- create a gradle task that can validate the response code and possibly an expected regex
- wire that check into CI.
The deprecation info API is used during upgrades to help users better understand the changes that are necessary before they upgrade. To help present this information each entry exposes an HTTP link for additional documentation. These HTTP links are embedded in the source code and like all remote links have the potential to be broken.
We recently switched to using shortened links which will allow us to better mitigate any broken links. However, we should also include some CI validation that these links are still good.
Ideally, with both shortened URLs and validation we could also consider opening the door to allow exceptions, deprecation logs, server logs, etc. to also embed HTTP links if it makes sense.
I assume we would need to :