Bigbluebutton: Unify Packet and Repository Naming to Correctly Reflect Minor Versions of BBB

[ichdasich]

Is your feature request related to a problem? Please describe.
At the moment, the repository and .deb of bbb 2.2 use 2.2.0 in the repository path and the package names. For example, bbb-2.2.5 comes from package bigbluebutton-2.2.0-5.

Especially when trying to install security updates, or verifying that they are installed, this leads to confusion.

Describe the solution you'd like
I suggest for 2.3 (no use in changing this for 2.2), to switch to only using the major versions of bbb in the repository path and properly incrementing minor versions for build packages analogous to the bbb version they are based on. So:

deb https://ubuntu.bigbluebutton.org/xenial-230 bigbluebutton-xenial main
becomes
deb https://ubuntu.bigbluebutton.org/xenial-23 bigbluebutton-xenial main

and, for a hypothetical bigbluebutton-2.3.4:
bigbluebutton-2.3.0-4
becomes
bigbluebutton-2.3.4-1
With increments of the last zero for changes to the package which do not change that it is based on bbb-2.3.4.

This way the expected behavior of being able to install all minors from a single repository is preserved, while making the actuall versioning more explicit.

Describe alternatives you've considered
If for whatever reason that change is not possible, it would be good to more explicitly document this in the BBB documentation, for example in a dedicated 'Update' section, next to the existing 'Install' section. In general, it might be good to already add that documentation for 2.2.

Additional Context

root@host:~# dpkg -l | grep bigblue
ii bigbluebutton 1:2.2.0-5 amd64 Open source web conferencing platform (bbb)

root@host:~# bbb-conf --check

BigBlueButton Server 2.2.5 (1848)
...

[ffdixon]

I maintain the packaging for BigBlueButton and we're going to make some of these improvements in the upcoming BigBlueButton 2.3 (due this summer).

For the current release, we've added the alias xenial-22 to point to xenial-220 in the packaging repository, and we'll be updating the documentation so it references xenial-22.

[einhirn]

If there was a way to keep the last few previous minor versions available after a new one is released, this would be great, too. I'd like to be able to install a specific release other than the current one - I'll even find out myself which packages in which versions belong to a release, but when the packages aren't available from the server anymore and I didn't download them before, I'll be out of luck.

Since the stakes for us are high, we'd like to check and double check whether a specific version works reliably - and be able to downgrade to the last "known-good" version, should the current chosen and tested one fail unexpectedly in production.

Currently we'd be forced to wait for the failure to be identified, fixed and for a new package to be released. Then we'd test the newly released package and would deploy it only after that - all while not having a working production environment. Yes, of course we can restore the server's "pre-upgrade"-state from backups - but only if the failure appears within the retention period of their specific backups...