-
Notifications
You must be signed in to change notification settings - Fork 2
v3.1.0 bis #164
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
v3.1.0 bis #164
Conversation
see https://humanwhocodes.com/blog/2019/01/stop-using-default-exports-javascript-module/ for details note that this constitutes a breaking change for developers
this is required in preparation of switching to ESM, where synchronous `require` will have to be replaced with dynamic `import` note that this constitutes a breaking change for developers
Bumps [actions/setup-node](https://github.com/actions/setup-node) from 3 to 4. - [Release notes](https://github.com/actions/setup-node/releases) - [Commits](actions/setup-node@v3...v4) --- updated-dependencies: - dependency-name: actions/setup-node dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <[email protected]>
Bumps [actions/checkout](https://github.com/actions/checkout) from 3 to 4. - [Release notes](https://github.com/actions/checkout/releases) - [Changelog](https://github.com/actions/checkout/blob/main/CHANGELOG.md) - [Commits](actions/checkout@v3...v4) --- updated-dependencies: - dependency-name: actions/checkout dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <[email protected]>
Bumps [browserslist](https://github.com/browserslist/browserslist) from 4.21.11 to 4.22.1. - [Changelog](https://github.com/browserslist/browserslist/blob/main/CHANGELOG.md) - [Commits](browserslist/browserslist@4.21.11...4.22.1) --- updated-dependencies: - dependency-name: browserslist dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <[email protected]>
Bumps [browserslist](https://github.com/browserslist/browserslist) from 4.22.3 to 4.24.4. - [Release notes](https://github.com/browserslist/browserslist/releases) - [Changelog](https://github.com/browserslist/browserslist/blob/main/CHANGELOG.md) - [Commits](browserslist/browserslist@4.22.3...4.24.4) --- updated-dependencies: - dependency-name: browserslist dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <[email protected]>
|
Thanks a lot! Don't worry about the other PR, I will rebase it later. Can you do the same PR for the |
|
I'm not entirely sure I understand what we've done there: So I assume that after releasing v3.0.0, we've decided that the v2 line needs independent adjustments - which is why the history diverges after v2.0.0? That in turn means we have a persistent release branch for the v2 line - which now needs this commit backported? Doing that for the code adjustment itself is trivial, of course, but I'm confused about 🆕 Taking a closer look, I think something went wrong there: v2.1.0's only meaningful adjustment is adding support for faucet-pipeline-assets (89cc443), plus adjusting Node support (7c8b86b). The three remaining commits are internal refactoring which is also present on I would suggest pulling both of those commits into |
Exactly!
Yes!
That is an oversight, we can add it 👍
Okay, I created a PR for cherry picking the changes back into the main branch in #165 - does that work for you? |
in the process, adjusted CI's Node support matrix
NB: this was backported to a newly established v2 release branch and
released as v2.1
|
Okay, so you will now take this PR, and adjust it so that it talks about 2.2 instead of 3.1, right? And then we can branch off the new 2.x branch, and release 2.2? |
this allows independent API consumers to perform operations at the end of the pipeline
|
Not quite: I would argue that patches should land on So IMO, we could land this PR and release v3.1 right away. PS: I've split this commit into two for consistency and to comply with README regulations. In fact, that might also simplify juggling release branches? |
|
superseded by #171 |
not sure how this relates to #150; I kinda lost track and will have to refamiliarize myself with that separately