VERSION

To-Do and Version Plan

Legacy Versioning Scheme - DreamBBS X.Y.Z; abbreviated as X.Y.Z

The versioning scheme originated from MapleBBS.

For MapleBBS 3, Y is a two digit number, e.g., 3.00 but not 3.0 and 3.02 but not 3.2.

Before the introduction of the new versioning scheme, the latest version name was WindTop 3.10 Rev.Beta 3 or DreamBBS 3.10 Rev.Beta 3, and the .Z part is not actually used.

Current Versioning Scheme - DreamBBS vX.Y.Z; abbreviated as vX.Y.Z

Note the presence of v.

Each release using the new versioning scheme has a corresponding legacy version number as well.

For DreamBBS v3, Y is an one digit number, e.g., v3.0 but not v3.00 and v3.2 but not v3.02. The next major release after DreamBBS v3.3 will be DreamBBS v4.0, so that Y will not be larger than 9.

It is acceptable to omit the v prefix for DreamBBS because using X.Y.Z along actually does not cause ambiguity:

• DreamBBS derived from MapleBBS not before MapleBBS 2.36, so before DreamBBS v3 (i.e., X < 3), DreamBBS X.Y refers to DreamBBS vX.Y but not MapleBBS X.Y
• DreamBBS v3 and MapleBBS 3 use different numbers of digits for Y, so DreamBBS 3.xx refers to MapleBBS 3.xx but not DreamBBS v3.xx, while DreamBBS 3.x refers to DreamBBS v3.x but not MapleBBS 3.x

The versioning scheme is deprecated. The version number X.Y.Z will be consistent with the legacy versioning scheme for DreamBBS 4.0.0/DreamBBS v4.0.0 and on.

Branches of Development

The new development workflow has led to the two main branches seen today: Release and current, which are explained in the following paragraphs.

From DreamBBS v3.0 and on, no dedicated git branches for releases will be created. Instead, new releases on the release development branch are published based on git tags from the master branch.

After v3.0, there are unstable branches for the convenience of testing as well: develop and <user>/develop.

The stages of the overall development workflow after v3.0, from the most unstable to the most stable:

• <user>/develop
  • The developer's develop branch for self-review
  • Other names can be used in place of the develop at the developer's intention
  • Force-updates can be performed at any time at the developer's intention
  • As soon as the commits themselves are checked to not have problems, these commits should be merged onto develop (fast-forwarding is preferred)
• develop
  • The branch for commits which need review from the maintainers
  • Force-updates require acknowledge and agreement from all maintainers in advance
  • As soon as the review are done, the commits should be merged onto master (fast-forwarding is preferred)
  • Pull requests should target this branch
• master
  • The stable branch where the functionality are reviewed by the maintainers
  • Force-updates should not be performed on this branch
• Releases
  • The git tags added on master at times
  • The referenced commit should not be changed after the changelog is published

Release Branch (formerly testing)

This branch emphasize more on the stability, the easiness to install, and the ability to deploy on different platform and containers, than the current branch.

Versioning Scheme: vX.Y.Z or just X.Y.Z after 4.0.0

• X: Major version; indicates significant changes
• Y: Minor version; indicates introduction of new features
• Z: Patch version; indicates bug fixes or security improvement; based on the previous version
• v0.Y refers to the branch for v0.Y.Z versions
• For X>0, vX.0 refers to the branch for vX.Y.Z versions

v0.95: Aka. 3.10 REV-BETA4 (3.10.95) ( End-of-Life )

The new versioning scheme is introduced in this minor version.

• v0.95.1: Aka. 3.10 REV-BETA4.1
• v0.95.2: Aka. 3.10 REV-BETA4.2
• v0.95.3: Aka. 3.10 REV-BETA4.3
• v0.95.4: Aka. 3.10 REV-BETA4.4; planned to be the last release of v0.95

It has become end-of-life when v0.97.0 was released.

v0.96 (3.10.96) ( End-of-Life )

The REV-BETA part in the version name is no longer used.

• v0.96.1
• v0.96.2
• v0.96.3

Features:

• Sorted common library and refined structure.
• Sample files are moved to another repository.
• Other detailed changes from current version.

It has become end-of-life when v0.97.1 was released.

v0.97: stratosphere (3.10.97) ( End-of-Life )

• v0.97-RCx-v0.97.0: Pre-release
• v0.97.1
• v0.97.2
• v0.97.3

Features:

• Simple code test utilities.
• Refined layout: Trailing whitespaces are removed.

v0.98-v0.99 (3.10.98-3.10.99)

The plans have been dropped due to significant changes which require comprehensive tests.

Pre-releases for v1.0 were planned instead:

• v1.0-alpha1
• v1.0-alpha2
• v1.0-alpha3
• v1.0-beta1
• v1.0-RC1
• v1.0-RC2
• v1.0-RC3

v1.X: Tensure series (3.11.X)

• v1.0.0: rimuru
• v1.1.0: milim; backports and improvement from current
  • Features:
    • Screen resizing feature.
• v1.1.1
  • Features:
    • pfterm, which was ported in this release version.
• v1.2.0: shizu
• v1.3.0: veldora

v2.X: Fate series (3.12.X) ( Latest Release Branch )

• v2.0.0: artoria
  • Features in plan:
    • Option for disabling DSO.
    • BBS-Lua/BBS-Ruby.
    • SHA-256-encrypted password support.
    • Preliminary WebSocket support, based on relevant patches to Maple3 and PttBBS.
• v2.1-rc1: gilgamesh (pre-release only)
  • Features:
    • Support building with CMake

202X vX (v3.X); Four Symbol series (3.21.X) ( Upcoming Release Branch )

The full name of this major version is DreamBBS-202X vX. 202X refers to the 2020s decade and is spelt literally this way.

This will be the last major version whose version number is different from the legacy version number.

Due to the shortage of development resources, from this major version and on, only the latest release version is officially maintained.

• 202X v0 (v3.0) (Testing)
  • Hot-swapping of DSO
  • Force using 32-bit int type structure member in native 64-bit environment
  • Full IPv6 support
  • Auto screen resizing
  • Server-side DBCS character detection
• 202X v1 (v3.1)
• 202X v2 (v3.2)
• 202X v3 (v3.3); planned to be the last release of v3.X

Features in plan:

• Built-in Big5-UAO/UTF-8 conversion support.
• Data races prevention using atomic variables and pthread mutexes.
• Replace System V shared memory API calls with POSIX shared memory API.
• Support using 64-bit time_t to make the BBS system to be immune to the 2038 problem.
  • 48 different structs need to be transformed
    • Not feasible in short-term
• Refactor out boilerplate code in xover list system
• Merge popup menu systems into main menu system
• Merge main menu system into xover list system

master Branch (Current Branch)

This branch has new features or significant changes which are being tested.

Former versioning scheme: vX.0-CURRENT

• The corresponding development branch for version vX.Y

Version scheme after v3.0:

1. The name of the latest release version for its development branch
2. Or X.Y-CURRENT for the development branch of upcoming release versions - Will be renamed into the real version name upon the official release

Whenever a significant bug fix or change is made in current, the related commits will be merged into testing branch for the latest release version soon.

However, from DreamBBS v3.0 and on, instead of merge the commits into the dedicated branch, a new release will be published soon.

• v1.0-CURRENT
• v2.0-CURRENT
• v3.0-CURRENT ( We are HERE )

Special Release Versions

Sometimes, special versions are released on special events.

April Fools' Day Event

• v4.20-alpha (2020) (Based on v3.0-CURRENT)
  • The main menu and the popup menu are movable
  • Every items in the main menu have a verbose explanation
• v4.20-beta (2021) (Based on 202X v0/v3.0)
  • The main menu and the Xover list have 2 cursors
  • The main menu and the popup menu are movable again

TODO

• Features from PttBBS to port and test:
  • Compilation tests for data structure size
  • pfterm (4-BSD)
  • BBS-Lua (MIT)
  • vtuikit (2-BSD)
  • nios (2-BSD)
  • logind (2-BSD)
  • WSProxy (MIT)
  • Note: (Maple3) visio = (Pirate/Ptt) term + screen/pfterm + io/(io + nios + vtkbd + vtuikit)
• Features from other Maple3 branches to port and test
  • Screen resizing
  • BBS-Ruby (MIT; Testing)
• Static Web Page Re-enabling