Skip to content

RCTab Versioning

Jump to bottom
Mathew Ruberg edited this page Aug 23, 2024 · 1 revision

RCTab Versioning

Given a version number MAJOR.UPDATE_PATH.PATCH, increment the:

  • MAJOR version when you make incompatible changes or you want to signify a “rollup” build
  • UPDATE_PATH version when you start an update path that you want control over how exposed it is to other development work.
  • PATCH version when you make enhancements or bug fixes within an UPDATE_PATH that has expectations for release outside of the development environment. All UPDATE_PATHs will start with PATCH = 0.

Benefits of this versioning scheme

  • We can work simultaneously on different UPDATE_PATHs, continuously improving within an UPDATE_PATH with new version numbers every time.
  • We have the discretion to include hotfixes from other UPDATE_PATHs if we want, or insulate an UPDATE_PATH from other development work if we need it to remain stable (e.g. during a prolonged certification event)
  • Any code update will have a corresponding version number update. Version numbers will only contain numbers.

Tradeoffs of this versioning scheme

  • 1.N+1.0 will not necessarily have everything in 1.N.0. It will be RCVRC responsibility when making releases to explicitly call out what has changed from 1.0.0, the last MAJOR version.
  • More complex branching // cherry picking could be required to insulate UPDATE_PATH
  • More testing effort required for a rollup

An Example

So let’s use an example. Let’s say we have 1.0.0 which was certified to EAC standards. It is out in the wild and being used by people. And then…

  • We are working on all the enhancements that people are asking for, what will eventually be 2.0.0. We identify our number one priority item, Enhancement A, and get started on it. Enhancement A development is complete, tested and verified. This is 1.999.0 - a special case for the UPGRADE_PATH to differentiate this as the “Release Candidate.”
  • We are asked by Vendor A to make a vendor-specific update that they can use with their product. This is 1.1.0.
  • We are asked by Vendor B to make some vendor-specific updates that they can use with their product. They are only interested in production ready, certified code being in their release. This is 1.2.0 - branched directly from 1.0.0. It does not have any un-certified 1.1.0 updates in it. It is submitted for certification.
  • There is a medium bug found in 1.0.0. It would be best for this to go to all versions, but not necessary. It is fixed in 1.0.0 as 1.0.1. We apply it to 1.1.0 and it becomes 1.1.1. We apply it to 1.999.0 and it becomes 1.999.1. We leave 1.2.0 as is - it is in the middle of certification.
  • We identify our number two priority item that we want to eventually belong in 2.0.0, Enhancement B, and get started on it. Enhancement B development is complete, tested and verified. This is 1.999.2.
  • We are barrelling along with enhancements to the 2.0.0 release candidate and developers have added 3 more enhancements. The RCTab department has space to review & test the latest changes. We decide to build the latest RC and start some preliminary testing. This is now 1.999.3.
  • Having planned ahead, the scheduled date for 2.0 development freeze arrives. We merge all the UPDATE_PATH branches that we want to bring forward into the RC branch as 1.999.4.
  • Internal testing finds no issues and we bump the RC to 2.0.0! This is delivered for certification.
  • During certification testing, some enhancements are requested to adhere to certification guidelines. This is 2.0.1. With these changes, the certification body finds 2.0.1 satisfies all requirements and is certified!

FAQ

When do Github releases happen?
Could be any of the above, but a new version number does not necessitate a Github release.

Why do we need rollups? Why not just keep UPDATE_PATHs indefinitely and only patch them when necessary?
There is a cost in development and testing to keep multiple UPDATE_PATHs. The more there are and the longer they stick around the more cost there is. Stricter UPDATE_PATHs that don’t take a lot of updates get stale. There are extra costs when you have to put newer enhancements/fixes into stale UPDATE_PATHs and vice-versa.

How can I keep track of all of the current UPDATE_PATHs?
Check the Active Branches Wiki on Github.

As a potential user of RCTab, where can I find the latest and greatest release?
The Github Release page. Release descriptions will include whether or not they have been certified, and what they have been certified for.

Branching Strategy

image

Dev FAQ

  • What branch does the rollup before a major release go into?
    • 1.999.4 in this visual. I’m imagining we make the decision to move all UPDATE_PATHs forward to the RC and then merge each into the RC branch. A round of testing occurs to confirm the merges didn’t introduce any issues. When confirmed the final commit is bumping the main.java version number. Then this is merged back into master after internal testing approval. Certification testing occurs on this 2.0.0. IF we give 2.0.0 to a cert body and they find some issues that need to be fixed, then that is 2.0.1. So TDP and documentation can say "RCTab 2.0" which will never change, but we can continue churning out uniquely versioned RC's until we are certified.
  • What about master and develop branches?
    • Master is the internally approved release + absolutely required hotfixes.
    • Develop acts as it currently does: master + any RC commits. Merged back into master after RC certification
Clone this wiki locally