Approach towards breaking changes

[captn3m0]

This has been pending for a while, but with recent breaking PRs from @marcwrobel I thought it would be a good time to focus a little bit on this.

I wrote up a doc on the Wiki for what I think will be a good approach: https://github.com/endoflife-date/endoflife.date/wiki/Breaking-Changes

Feedback is welcome. On the maintainer front, as long as we have a good shared understanding of what is a breaking change, I think we can figure out the rest over time. There's some automation suggestions that I'd like to take up.

[ShreyMarwaha]

Following up from the discussion #7632, I wanted to express strong support for some sort of opt-in mailing list as one of the key communication channels for critical API updates and deprecations.

For users integrating endoflife.date data, having a direct and universally accessible method to be notified of breaking changes and critical updates is paramount. An opt-in email subscription would provide the most reliable and universally accessible method for ensuring users are proactively aware of critical changes.

[captn3m0]

I setup a mailing list using buttondown last night. Still want to paper over a few quirks, and setup web pages for subscription etc, but plan is to create two separate newsletters:

• eol-announce for announcements, such as breaking changes or API launches etc.
• An untitled newsletter about Support timelines. This would include a summary of new products, as well as other stuff in the ecosystem.

Subscription via RSS etc should be possible as well.

[marcwrobel]

We already have talk pages for each product:
.

They are wiki pages, but by converting them to discussions we could do the announcement there (discussions can be followed). The idea to use discussion instead of wiki pages was already rejected (#2286) but maybe we could reconsider @captn3m0 ?

For API we could have a dedicated discussion too.

Note that for those that don't want to subscribe to discussions on GitHub, it seems discussions could be turned to an RSS feed using https://openrss.org/feeds/github.

[captn3m0]

I like the idea of using Discussions as Talk pages, but that obviously means that talk pages will be used for non-breaking change discussions as well. It also has another problem: we need to pre-create all discussion pages (wiki pages can be created on demand), and maintain stable links to them. But that should be a solvable problem I think via tags and the GitHub API perhaps.

But we need a notification space that is limited to "Breaking and Major changes across all pages". We can maybe have a single discussion for that (for a single notification source), but that will just get confusing. Better to keep our current format: PRs that are labelled, and then we generate a RSS feed from those labelled PRs, and send that across email and other mediums.

[marcwrobel]

but that obviously means that talk pages will be used for non-breaking change discussions as well

Discussions about products are rare, and it can be interesting to have the opinion of people willing to follow the discussion for breaking changes.

another problem: we need to pre-create all discussion pages

Yes, that's a real issue. I agree it's not unsolvable, but it's a pain.

But we need a notification space that is limited to "Breaking and Major changes across all pages".

I am not so sure : I think it's more probable that users want alerts for a few products. Having a notification for all products would likely produce more messages than a discussion for a single product.

Better to keep our current format: PRs that are labelled, and then we generate a RSS feed from those labelled PRs, and send that across email and other mediums.

Any progress on this ?