Skip to content

v3.1.0 bis#164

Closed
FND wants to merge 15 commits into
mainfrom
v3.1
Closed

v3.1.0 bis#164
FND wants to merge 15 commits into
mainfrom
v3.1

Conversation

@FND

@FND FND commented Oct 29, 2025

Copy link
Copy Markdown
Contributor

extended faucetDispatch to report completion of the initial build

this allows independent API consumers to perform operations at the end of the pipeline

not sure how this relates to #150; I kinda lost track and will have to refamiliarize myself with that separately

FND and others added 11 commits January 17, 2023 10:31
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] <support@github.com>
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] <support@github.com>
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] <support@github.com>
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] <support@github.com>
@FND
FND requested a review from moonglum October 29, 2025 09:58
@moonglum

moonglum commented Oct 29, 2025

Copy link
Copy Markdown
Member

Thanks a lot! Don't worry about the other PR, I will rebase it later.

Can you do the same PR for the 2.x branch? Then we can release a new version in the 2 line, and actually use it 😉

@FND

FND commented Oct 29, 2025

Copy link
Copy Markdown
Contributor Author

I'm not entirely sure I understand what we've done there:

  • main ≙ 🏷️ v3.0.0 (dae1cd5)
  • 2.x ≙ 🏷️ v2.1.0 (89cc443)
  • common ancestor is 🏷️ v2.0.0 (8e4f684)

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 CHANGELOG.md: The v2.1.0 entry is missing from the v3 line's change log. Is that an oversight or intentional?

🆕 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 main, but with different commit hashes for no discernible reason.

I would suggest pulling both of those commits into main, including change-log adjustments (under a WIP version though). Then we can retroactively fix the v2.1.0 tag by starting anew from b5ee75a and backporting (cherry-picking) those two commits from main into a new 2.x branch.

@moonglum

Copy link
Copy Markdown
Member

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?

Exactly!

That in turn means we have a persistent release branch for the v2 line - which now needs this commit backported?

Yes!

The v2.1.0 entry is missing from the v3 line's change log. Is that an oversight or intentional?

That is an oversight, we can add it 👍

I would suggest pulling both of those commits into main, including change-log adjustments (under a WIP version though). Then we can retroactively fix the v2.1.0 tag by starting anew from b5ee75a and backporting (cherry-picking) those two commits from main into a new 2.x branch.

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
@moonglum

Copy link
Copy Markdown
Member

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?

FND added 2 commits October 30, 2025 09:13
this allows independent API consumers to perform operations at the end
of the pipeline
@FND

FND commented Oct 30, 2025

Copy link
Copy Markdown
Contributor Author

Not quite: I would argue that patches should land on main first and then be backported to dedicated release branches.

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?

@FND

FND commented Nov 3, 2025

Copy link
Copy Markdown
Contributor Author

superseded by #171

@FND FND closed this Nov 3, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants