Skip to content

Conversation

@FND
Copy link
Contributor

@FND FND commented Oct 29, 2025

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] <[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]>
@FND FND requested a review from moonglum October 29, 2025 09:58
@moonglum
Copy link
Member

moonglum commented Oct 29, 2025

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
Copy link
Contributor Author

FND commented Oct 29, 2025

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
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
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
Copy link
Contributor Author

FND commented Oct 30, 2025

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
Copy link
Contributor Author

FND commented Nov 3, 2025

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.

3 participants