Skip to content

Release Plan: 5.1.0 #6316

Closed
Closed

Description

@wesleytodd

Remaining Work

Dependency work

Not planned for this release

Activity

  1. dpopp07 commented on Feb 3, 2025

    @dpopp07
    Contributor

    I'm happy to open a small PR with the semver range changes.

  2. dpopp07 commented on Feb 20, 2025

    @dpopp07
    Contributor

    PR to address router issue: pillarjs/router#151

    Edit: sibling PR to the above for documenting the router change in the migration guide: expressjs/expressjs.com#1819

  3. UlisesGascon commented on Mar 23, 2025

    @UlisesGascon
    Member

    Ok, so following #6412 my current understanding of the release plan and the blockers is the following (@wesleytodd please edit this 🙏 ). Also I was fishing some items from expressjs/discussions#266

    Current proposal

    What's Changed

    New Contributors

    Full Changelog: 5.0.1...master

    Pending Work

    Express Work

    Potential additions
    What do you think @wesleytodd? Maybe we can include them while unblocking other parts?

    Final Work

    • Prepare a PR with the version bump to 5.1.0 and the full changelog (@wesleytodd )
    • Create a github release and a git tag for 5.1.0 (@wesleytodd )
    • Publish the version in npm (@wesleytodd)
    • Social Media promotion (@wesleytodd )

    Dependencies

    Level 0 (Express itself)

    Level 1

    Level 2

    Level 3

    • content-type has no relevant changes or releases pending
    • encodeurl has no relevant changes or releases pending
    • etag has no relevant changes or releases pending
    • fresh has no relevant changes or releases pending
    • mime-types@3.0.1
    • media-typer has no relevant changes or releases pending
    • negotiator has no relevant changes or releases pending
    • on-finished has no relevant changes or releases pending
    • range-parser has no relevant changes or releases pending
    • http-errors has no relevant changes or releases pending

    Level 4

    • mime-db@1.54.0 is out (npm, release details)
    • statuses has no relevant changes or releases pending
  4. bjohansebas commented on Mar 23, 2025

    @bjohansebas
    Member

    Btw, the change of engines in path-to-regexp needs to be a major release.

  5. UlisesGascon commented on Mar 23, 2025

    @UlisesGascon
    Member

    Btw, the change of engines in path-to-regexp needs to be a major release.

    True! actually if we want to go with 9.0.0 is a good option, otherwise I can revert the commit partially to be semver compatible. WDYT (@bjohansebas @wesleytodd ) ?

  6. bjohansebas commented on Mar 23, 2025

    @bjohansebas
    Member

    I think we should stick to version 8. I don't think we should release another version of path-to-regexp unless we want to make other types of changes (such as releasing a dual package (commonjs and ems), moving to ESM, or achieving safer regex for string patterns).

  7. jonkoops commented on Mar 24, 2025

    @jonkoops
    Contributor

    What is the ESM transition plan for these dependencies (if any)? In April, support for Node.js 18 will be dropped, which is the last version of Node.js that does not support interoperability between CommonJS and ESM. So technically, that would be a good moment to raise the minimum version and do a full ESM conversion. If you are short on hands for this effort, I can volunteer my time to get it done, if so desired.

  8. panva commented on Mar 24, 2025

    @panva

    Is 5.1.0 going to be tagged as @latest on npm?

  9. bjohansebas commented on Mar 24, 2025

    @bjohansebas
    Member

    Yes, 5.1.0 will be the latest version when it is released

  10. panva commented on Mar 24, 2025

    @panva

    That's good to know, issues spanning from req.host not being an actual url host component (i.e. incl. port) will go away as people slowly upgrade. So far with v5 being tagged as @next it was hard to get people to upgrade.

  11. wesleytodd commented on Mar 27, 2025

    @wesleytodd
    MemberAuthor

    What is the ESM transition plan for these dependencies

    @jonkoops, you can read more about that here: expressjs/discussions#323

    Is 5.1.0 going to be tagged as @latest on npm?

    express and all of it's direct dependents we had kept at next while express was will be going latest.

    That's good to know, issues spanning from req.host not being an actual url host component (i.e. incl. port) will go away as people slowly upgrade. So far with v5 being tagged as @next it was hard to get people to upgrade.

    @panva Do you have some node issues I can link to when we talk about this? It is near impossible to get folks to upgrade even if it is latest but we can try with good messaging.

  12. changed the title [-][WIP] Release Plan: 5.1.0[/-] [+]Release Plan: 5.1.0[/+] on Mar 27, 2025
  13. panva commented on Mar 27, 2025

    @panva

    Do you have some node issues I can link to when we talk about this? It is near impossible to get folks to upgrade even if it is latest but we can try with good messaging.

    @wesleytodd Having express as a dependency of a passport strategy - it is a real struggle to be able to determine the request's original href without both replicating express' internals and changing the resolution code based on the app's trust proxy setting. This is stemming from the fact that req.host in v4 is the hostname and not the host and there's no host getter that would take trust proxy into consideration.

    refs: panva/openid-client#767, panva/openid-client#743, panva/openid-client#733, panva/openid-client#746, panva/openid-client#713, panva/openid-client#714

    v5 behaves as expected but unfortunately in v4 the code doesn't work for development on localhost with arbitrary ports, and in production with non http scheme default ports (i.e. other than 80 and 443).

    I've resisted the pressure of accomodating the bugged v4 behaviour and just explained to users they need to either upgrade to v5 or overload the method that returns the current URL in development setups. In v4 the req.host should have been fixed instead of being deprecated and console warned upon use in the first place. I get a few issues opened every now and then because of it.

    It is near impossible to get folks to upgrade even if it is latest but we can try with good messaging.

    I get that. But at least having latest be v5 means new apps will default to v5 with npm i express and the transition to v5 can begin for real in userland.

  14. jonkoops commented on Mar 27, 2025

    @jonkoops
    Contributor

    @jonkoops, you can read more about that here: expressjs/discussions#323

    Thanks, I will subscribe there 👍

  15. wesleytodd commented on Mar 28, 2025

    @wesleytodd
    MemberAuthor

    Proposed release: #6425

    I will close this in favor of moving any conversation there now that we have a PR.

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

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions