[New Product] Add RDS Postgres

[CodaBool]

If you are wondering why you need another postgres release page. This proposed page would be for the AWS RDS releases. Which follow about a month behind and have their own end of life dates.

There is no AWS API to get End of life dates for RDS databases.

I wrote a script to scrape the dates on this page.

I probably could improve the bottom markdown section after the front matter. So let me know if I'm missing something.

I also plan on scaping and adding a page for mysql 🙂

[welcome]

Thank you for opening this pull request 👍. If you are not familiar with the project, please check out our Contributing Guidelines and our Guiding Principles. Also take a look at our Hacking Guide if you intend to work on site internals.

[CodaBool]

could someone please tell me how I am getting an invalid date from this file?

https://raw.githubusercontent.com/CodaBool/endoflife.date/master/products/rds-postgres.md

I have resorted to copying example values from a merged PR of Amazon Corretto. As an attempt to get valid dates.

https://raw.githubusercontent.com/endoflife-date/endoflife.date/bb5bcac2d06f3a6f84933de1cde532a22c83ee8b/products/amazon-corretto.md

I am at a loss for what I am doing wrong besides trying to re-implement some of your tests locally.

My actual file I want to commit is dd17b64 but I'm just committing different attempts to debug

[marcwrobel]

Hi @CodaBool, I think it's the same issue as #2626 (comment).

[marcwrobel]

This PR must be reviewed only after #2626 is merged. Those products are similar.

[marcwrobel]

@CodaBool, I squashed all your commits in d915b13.

Then I aligned the format / description with https://endoflife.date/amazon-rds-mysql. I also fixed some dates and updated latest releases. Can you have a look ?

Do not forget to pull the latest commits if you need to update the PR.

[CodaBool]

Sure, I can do that. Thank you.

[captn3m0]

Read through the relevant upstream pages, and I think we should split this into one release cycle per minor version, skipping over unsupported versions, and hiding the latest column.

Primarily to avoid users running a supported version (say 14.6) getting incorrect suggestion to upgrade to 14.7, when it is still a supported release.

There's a bunch of versions going EOL on 20th March (10.17-10.21, 11.12, 11.13, 12.7-12.9, 13.3.-13.6, 14.1, 14.2) which we can skip over to avoid making the table huge - the default assumption is that any version that doesn't show up in the table is unsupported. It will still be large (20-25 rows), but I think that's reasonable for such a product.

[marcwrobel]

Not sure because that is not consistent with the strategy I took for Amazon RDS for MySQL, which is really close to that product in term of version management (#2626 (comment)).

On Amazon RDS for MySQL, major versions are x.y and minor are x.y.z (https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/MySQL.Concepts.VersionMgmt.html#MySQL.Concepts.VersionMgmt.ReleaseCalendar). But for PostgreSQL major are x and minor are x.y (https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-release-calendar.html#Release.Calendar).

If we want to be consistent we should make the same choice for both products. The current choice is to document only major.

Primarily to avoid users running a supported version (say 14.6) getting incorrect suggestion to upgrade to 14.7, when it is still a supported release.

That's the hard part indeed, but they also say on https://aws.amazon.com/rds/faqs/#How_do_I_control_if_and_when_the_engine_version_of_my_DB_instance_is_upgraded_to_new_supported_versions.3F :

We recommend that you keep your database instance upgraded to the most current minor version as it will contain the latest security and functionality fixes. Unlike major version upgrades, minor version upgrades only include database changes that are backward-compatible with previous minor versions (of the same major version) of the database engine.

And :

Periodically, we will deprecate major or minor engine versions. Major versions are made available at least until the community end of life for the corresponding community version or the version is no longer receiving software fixes or security updates. For minor versions, this is when a minor version has significant bugs or security issues that have been resolved in a later minor version.

That's what makes me think we should stick with major versions.

[CodaBool]

I agree with @marcwrobel major versions would be best here.

I think that keeping the latest column is best. It's a good compromise between providing helpful supported version information and not adding too much to make it unmaintainable.

🚩Update

I have a related update to announce. I created a new PR over at the release-data repo. This adds a modified version of my script I originally wrote for these 2 RDS PRs.

What's different about this is that it is an automated way to gather all data on the AWS docs. The important detail here is that minor and major versions are included. So, this might solve some of the issues discussed here. Since if people are wanting minor version deprecation dates they can view them from there.

[marcwrobel]

Just did another review, will merge.

@captn3m0 let's handle the major / minor versions debate in another PR.