Skip to content

CI should run against latest Postgres versions #8192

Closed
#8191
Closed
CI should run against latest Postgres versions#8192
#8191
Labels
state:releasedReleased as stable versionstate:released-5.x.xReleased as LTS versionstate:released-alphaReleased as alpha versionstate:released-betaReleased as beta versiontype:ciCI related issue

Description

@cbaker6
cbaker6
opened on Sep 22, 2022

New Feature / Enhancement Checklist

Current Limitation

The CI isn't testing against the current latest versions of dependencies (e.g. Postgis 3.3) and still testing against dependencies that has reached the Parse EOL. This prevents the CI from determining if there are issues with the latest versions along with running unnecessary tests for each PR.

Feature / Enhancement Description

Update versions of Postgis, remove versions that have reached EOL: Postres 11, Postgis 3.0, Node 12, Mongo 4.0, Mongo MMAPv1.

Example Use Case

N/A

Alternatives / Workarounds

Test latest versions on our own.

3rd Party References

N/A

Activity

  1. parse-github-assistant commented on Sep 22, 2022

    @parse-github-assistant
    parse-github-assistantbot
    on Sep 22, 2022

    Thanks for opening this issue!

    • 🎉 We are excited about your ideas for improvement!

  2. mtrezza commented on Sep 22, 2022

    @mtrezza
    mtrezza
    on Sep 22, 2022
    Member

    Removing support for a database or node major version is a breaking change, which we'll do with Parse Server 6.
    Therefore we do have specific open issues for that, e.g. #8081.

    So it makes more sense to separate this PR into:

    • a) Removing support for versions that won't be supported anymore by Jan 1st 2023 according to their EOL date; to be merged with release of Parse Server 6. I recommend to create a separate PR for each removal of support, because it may involve more than just changing the workflow file. For example, there are also tests that run only for specific versions, that may need to be updated.
    • b) Upgrading (minor or patch versions) of currently supported versions; can be merged immediately.

    Btw, MongoDB and Node.js patch versions are updated automatically with a script that detects whether there is a newer version available. It would be good if someone could extend that script to include Postgres.

  3. mtrezza
    added
    type:ciCI related issue
    on Sep 22, 2022

  4. cbaker6 commented on Sep 22, 2022

    @cbaker6
    cbaker6
    on Sep 22, 2022
    ContributorAuthor

    a) Removing support for versions that won't be supported anymore by Jan 1st 2023 according to their EOL date; to be merged with release of Parse Server 6. I recommend to create a separate PR for each removal of support, because it may involve more than just changing the workflow file. For example, there are also tests that run only for specific versions, that may need to be updated.

    For the PR, I didn't remove any code in the repo or tests, so the code to handle those versions is untouched. They are simply not tested in the CI anymore in the PR. This allows developers to manually test on old versions that have reached Parse Server EOL if they want until someone decides to remove the code in the future (see discussion here).

    Btw, MongoDB and Node.js patch versions are updated automatically with a script that detects whether there is a newer version available. It would be good if someone could extend that script to include Postgres.

    The Postgres components of the CI already do patch updates from the way I added them to the CI a long time ago (Minor/patch of Postgres, Minor of Postgis). Minor versions of Postgis need to be bumped manually. See the original comment in the approach section of #7176 for more

  5. mtrezza commented on Sep 22, 2022

    @mtrezza
    mtrezza
    on Sep 22, 2022
    Member

    For the PR, I didn't remove any code in the repo or tests, so the code to handle those versions is untouched. They are simply not tested in the CI anymore in the PR.

    We don't operate like that. A versions is officially supported by Parse Platform as long as it's tested in the CI and vice versa.

    The Postgres components of the CI already do patch updates from the way I added them to the CI a long time ago

    What about this change in your PR:

    - name: PostgreSQL 14, PostGIS 3.2
- POSTGRES_IMAGE: postgis/postgis:14-3.2
+ name: PostgreSQL 14, PostGIS 3.3
+ POSTGRES_IMAGE: postgis/postgis:14-3.3

  6. cbaker6 commented on Sep 22, 2022

    @cbaker6
    cbaker6
    on Sep 22, 2022
    ContributorAuthor

    What about this change in your PR:

    • name: PostgreSQL 14, PostGIS 3.2
    • POSTGRES_IMAGE: postgis/postgis:14-3.2
    • name: PostgreSQL 14, PostGIS 3.3
    • POSTGRES_IMAGE: postgis/postgis:14-3.3

    The sermver states:

    Given a version number MAJOR.MINOR.PATCH, increment the:

    MAJOR version when you make incompatible API changes
    MINOR version when you add functionality in a backwards compatible manner
    PATCH version when you make backwards compatible bug fixes
    Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.

    Therefore what I stated earlier holds:

    The Postgres components of the CI already do patch updates from the way I added them to the CI a long time ago (Minor/patch of Postgres, Minor of Postgis). Minor versions of Postgis need to be bumped manually. See the original comment in the approach section of #7176 for more

  7. cbaker6 commented on Sep 22, 2022

    @cbaker6
    cbaker6
    on Sep 22, 2022
    ContributorAuthor

    a) Removing support for versions that won't be supported anymore by Jan 1st 2023 according to their EOL date; to be merged with release of Parse Server 6.
    We don't operate like that. A versions is officially supported by Parse Platform as long as it's tested in the CI and vice versa.

    If this is the case, I recommend coming up with a better way to describe EOL in the README. It's currently based on dates:

    image

    which is not what your comment above states. Maybe is should be based on Parse-Server Major version releases?

  8. mtrezza commented on Sep 22, 2022

    @mtrezza
    mtrezza
    on Sep 22, 2022
    Member

    Minor versions of Postgis need to be bumped manually.

    Right, I overlooked that. Extending the script we use for MongoDB and Node would still be nice, it also notifies about new major / minor versions available.

    I recommend coming up with a better way to describe EOL in the README.

    The wording is from before we introduced calver versioning. Now we could simplify this to:

    Due to the extensive PostgreSQL support duration of 5 years, Parse Server drops support about 2 years before the official end-of-life date.

    Version PostGIS Version End-of-Life Parse Server Support Compatible
    Postgres 11 3.0, 3.1, 3.2 November 2023 <= 5.x (2022) ✅ Yes
    Postgres 12 3.2 November 2024 <= 5.x (2022) ✅ Yes
    Postgres 13 3.2 November 2025 <= 6.x (2023) ✅ Yes
    Postgres 14 3.2 November 2026 <= 7.x (2024) ✅ Yes

    According to that, Postgres 11 should already have been unsupported from Parse Server 5. The first release date of PG 11 was October 18, 2018, so we would have supported it for >3 years. PG 12 was released October 3, 2019, so the newer version was available for >2 years before we would have dropped support. Essentially we give developers 2.25 years to upgrade to the next PG version.

    Compared to MongoDB, they give developers ~2.5-2.75 years to migrate to the next higher version.
    Compared to Node.js, they give developers ~2 years to migrate to the next higher LTS version.

    That means in 3 months (Parse Server 6) we'll drop support for Postgres 11 and 12, but it will stay supported in our LTS branch for an additional year until end of 2023.

    Does this make sense?

  9. mtrezza
    linked a pull request that will close this issueci: upgrade Postgres versions #8191on Sep 22, 2022
  10. mtrezza
    changed the title [-]CI should run against latest versions[/-] [+]CI should run against latest Postgres versions[/+] on Sep 22, 2022
  11. mtrezza
    closed this as completedin #8191on Sep 23, 2022

  12. parseplatformorg commented on Sep 29, 2022

    @parseplatformorg
    parseplatformorg
    on Sep 29, 2022
    Contributor

    🎉 This change has been released in version 5.3.0-alpha.27

  13. parseplatformorg
    added
    state:released-alphaReleased as alpha version
    on Sep 29, 2022

  14. parseplatformorg commented on Oct 29, 2022

    @parseplatformorg
    parseplatformorg
    on Oct 29, 2022
    Contributor

    🎉 This change has been released in version 5.4.0-beta.1

  15. parseplatformorg
    added
    state:released-betaReleased as beta version
    on Oct 29, 2022

  16. parseplatformorg commented on Oct 31, 2022

    @parseplatformorg
    parseplatformorg
    on Oct 31, 2022
    Contributor

    🎉 This change has been released in version 5.4.0-alpha.1

  17. parseplatformorg commented on Nov 19, 2022

    @parseplatformorg
    parseplatformorg
    on Nov 19, 2022
    Contributor

    🎉 This change has been released in version 5.4.0

  18. parseplatformorg
    added
    state:releasedReleased as stable version
    on Nov 19, 2022

  19. parseplatformorg commented on Nov 19, 2022

    @parseplatformorg
    parseplatformorg
    on Nov 19, 2022
    Contributor

    🎉 This change has been released in version 5.4.0

  20. parseplatformorg
    added
    state:released-5.x.xReleased as LTS version
    on Nov 19, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    state:releasedReleased as stable versionstate:released-5.x.xReleased as LTS versionstate:released-alphaReleased as alpha versionstate:released-betaReleased as beta versiontype:ciCI related issue

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions