Skip to content

Latest commit

 

History

History
511 lines (226 loc) · 27 KB

File metadata and controls

511 lines (226 loc) · 27 KB

RELEASE NOTES

All notable changes to this project will be documented in this file.

The format is based on Keep a Changelog, and this project adheres to a flavor of Semantic Versioning which includes Scopes and Epochs.


Quick Navigation

Scope Current Release Commit Count
Electron 39.2.6 54 commits
Forge 7.0.0 22 commits
Remoting 7.0.0 28 commits

Electron

39.2.6 - (2025-12-14)

Added

Fixed

Others

6.0.0 - (2020-05-24)

Others

5.5.0 - (2020-05-16)

Others

5.4.0 - (2020-04-04)

Others

5.3.0 - (2020-03-28)

Others

5.2.0 - (2020-03-21)

Others

5.1.0 - (2020-02-24)

Others

5.0.0 - (2020-02-10)

Others

4.3.0 - (2019-12-08)

Others

4.2.0 - (2019-11-09)

Others

4.1.0 - (2019-11-06)

Others

4.0.0 - (2019-11-01)

Others

3.0.0 - (2019-09-11)

Others

2.0.0 - (2019-08-20)

Others

1.0.0 - (2019-07-31)

Others


Forge

7.0.0 - (2025-12-14)

Added

Fixed

Others


Remoting

7.0.0 - (2025-12-14)

Added

Fixed

Others



Read more about this SemVer flavor

Epoch Scoped SemVer

This flavor adds an optional marketable value called an EPOCH. There is also an optional disambiguating SCOPE identifier for delineating tags for packages in a mono repo.

The motivation for this is to prevent resistance to utilising SemVer major bumps correctly, by allowing a separate marketable identifier which is easily compatible with the current SemVer spec.

An Epoch/Scope (Sepoch) is an OPTIONAL prefix to a typical SemVer.

  • A Sepoch MUST BE bounded by _ underscores _.
  • The identifiers MUST BE ALPHABETICAL (A-Za-z) identifiers.
  • The Epoch SHOULD BE upper case
  • The Epoch MUST come before the Scope, if both are present.
  • The Scope MUST additionally be bounded by ( parenthesis ).
  • The Scope SHOULD BE capitalised/pascal cased.
  • A Sepoch CAN BE separated from SemVer by a single white space where this is allowed (ie not allowed in git tags).
  • Epoch DOES NOT influence precedence.
  • Scope MUST uniquely identify a single components versioning.
  • Different scopes CANNOT BE compared for precedence.
  • A SemVer without a Scope CAN BE compared to a Scoped SemVer for compatibility. But caution is advised.

There is no enforcement for ordering EPOCHs in this spec, as it would be overly restrictive and yield little value since we can delineate and earlier EPOCH from a later EPOCH by the SemVers.

Example

gitGraph
commit tag: "_ALPS_1.2.3"
branch develop
commit id: "add: ..."
commit
checkout main
cherry-pick id: "add: ..." tag: "_ALPS_2.1.3"
checkout develop
commit
commit
checkout main
merge develop tag: "_ALPS_3.4.5"
checkout develop
commit
commit
checkout main
merge develop tag: "_BRAVO_4.0.0" type: HIGHLIGHT
Loading

While there are breaking changes between versions 1 to 3, we expect that it is less than from 3 to 4. We expect the API surface would change more dramatically, or there is some other significant milestone improvement, in the change from version 3 epoch ALPS to version 4 epoch BRAVO.

_WILDLANDS(Core)_ 4.2.0
_WILDLANDS(Engine)_ 0.5.3
_DELTA(Core)_ 5.0.0
_DELTA(Engine)_ 0.5.3

Cannot be compared to Core versions. Both Engine versions are equal, we can identify that the ecosystems marketed change does not change the Engine packages API