Document bbb_version (RAP compat versioning) bumping criteria in record-and-playback config

Open Beginner friendly
#25,702 6 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
1/5
Estimated time
Under an hour
Newbie friendliness
92/100
Issue type
Documentation
Clarity
Clearly specified
Activity status
Active
Tech stack
javascript, ruby, yaml
Domain
documentation

Research direction

Start at record-and-playback/core/scripts/bigbluebutton.yml:1, then review events_archiver.rb:252 and :270 and publish/presentation.rb:905 to confirm how bbb_version is used. Done when an inline comment documents RAP compatibility semantics, its independence from the server version, and the criteria for bumping it, without changing configuration behavior.

Written by the indexing model from the issue text.

Description

Goal (updated after discussion): add an inline comment next to the bbb_version key in record-and-playback/core/scripts/bigbluebutton.yml explaining what the value means (RAP compatibility versioning, decoupled from the BBB server version) and when it gets bumped (on relevant RAP changes, e.g. a new event or an event change, so downstream processors can tell versions apart). No rename, no refactor.

Background

Recording artifacts are stamped bbb_version="3.0.17" regardless of the server version (observed on 4.0.0-beta.5 from-source, and at the current tip of v4.0.x-develop). The value comes from the hand-maintained literal at record-and-playback/core/scripts/bigbluebutton.yml:1, consumed by events_archiver.rb:252, stamped once into events.xml (events_archiver.rb:270) and carried into the published tldraw.json (publish/presentation.rb:905).

As discussed below, this decoupling is intentional: the field tracks RAP versioning, not the BBB server version, and has meant that since at least BBB 0.9. The remaining gap is documentation - readers of the artifacts (and of the config) reasonably assume bbb_version reflects the server version that produced the recording, which is exactly the confusion this issue tripped over. An inline comment stating the semantics and bump criteria closes that gap without breaking any downstream pattern.

For reference, the current consumers of this value compare with >= only, with thresholds at most 2.6.0 in the monorepo (events.rb:1317, presentation process/publish scripts) and at most 3.0.0 in bbb-playback (src/components/player/content/index.js:41), so no processing branch is affected today.

Dominant language
JavaScript
Stars
9.2k
Forks
6k
Avg merge
2d 1h
Merged PRs (30d)
80

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from bigbluebutton/bigbluebutton

All issues in bigbluebutton/bigbluebutton

Similar issues

More JavaScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.