[paulsohn]

User-Facing Changes

Add support for foxglove.sdk.v1 WebSocket subprotocols.
As stated in the current Foxglove developer's stance, currently this subprotocol is identical to foxglove.websocket.v1, so supporting subprotocol is just adding the new subprotocol name alongside the older one, and the end user need not to distinghish the Foxglove bridge 3.2.1 and 0.8.x.

Resolving #547 #604 #750 . Duplicate of #772 (closed and reopened due to branch name restriction)

Description

Checklist

• The web version was tested and it is running ok
• The desktop version was tested and it is running ok
• This change is covered by unit tests
• Files constants.ts, types.ts and *.style.ts have been checked and relevant code snippets have been relocated

[paulsohn]

@rodrigo-rodrigues-ctw

Just curious, is there any motivation to keep branch protection rules based on branch name? If I was working on this repository then yes the branch name would matter, but I'm working on the forked one.

I'd rather lease the constraint to the internal branches, and check semantic PR title rather than branch name, because

• all PRs are squash-merged and the commit message will be PR title, so it is more persistent one (unlike branch name that would be irrelevant after PR merge)
• As this case demonstrates, if someone created with PR with incorrect branch name, then they cannot change it by other than closing and reopening after the branch name change, which takes significant working cost. In constrast, changing PR title is easy.

[ctw-joao-luis]

Hi @paulsohn, thanks for reopening the PR.

The current branch name based protection rules were originally set up to ensure consistency when contributors were working directly in the main repo. Since you're working from a fork, I agree that the branch name can become a little less relevant.

We can see internally if it makes sense to enforce them on PRs from outside contributors and if there’s no strong objection from others, we can relax this rule externally, and rely on semantic PR titles for consistency.

Cheers,
JL