Git Promises

Version Bumps while Beta-testing

• Now i will talk about how the current Vecto release process

• deals with unforseen features & bugfixes.

• Let’s assume that we plan to release version 4.0.0 - dates are not important here.

• We just have PROMISED that specific version-id.

• The development starts…

  • and after all foreseen features & bugfixes are in place, …
  • we publish a "Release Candidate" for our BETA testers.

  COMMENT: publishing a "BETA" is also similar

• While awaiting feedback from testers …

• an UNFORSEEN feature gets merged,

  • for example, JRC propores VTP.

• The Q is: should the new merge affect the version-number?

COMMENT: assuming no code-freeze enacted after RC…

• Based on the promise,… we should NOT!

  • Bumping the RC number is the only possibility.

• BUT we’re now 2 development teams,

• Semantic Versioning facilitate communications.

• versionS 4.1.x would be much easier to remember

• that it is all these version that contain VTP.

• To conclude, it is the promise that prevent us fron using version IDs to their full potential.

Faulty Releases

• I want to talk about the current Vecto release process, specifically, …

  • how it deals with faulty packages.

• Let’s assume that we’re on May, and

  • we plan to release version 3.15 on June.

COMMENT: talking about 2-number versions for brevity

• That’s a PROMISE for version 3.15 on a rough date.

• We implement the foreseen bugs & features, …

  • update all DOCUMENTS in the sources,
  • add the Release Candidate marker, ..
  • commit, and …
  • publish the new "RC" to our BETA testers.

• Based on their feedback,

  • we do any final fixes,
  • edit ALL DOCS once more to remove the "RC" marker, AND …
  • to mention it’s now a release Blessed for Certification,
  • commit, release, and …
  • this time, announce it, to ALL our Users.

• The working assumption HERE is that users reported back the release as BROKEN!

• What do we do?

• Certainly we need another release, but what version should that be?

• Same as before? …version 3.15??

  • That would confuse BOTH the Users, and the Computers.

• For the Users, …they need a significant digit bump on the version-string, …

  • to discern the NEW 3.15 from the OLD one.

• That’s what Semantic Versioning stands for.

COMMENT: Vecto uses 4th element build-day incompatible with SemVer & NuGet

• For DevOps, both CI & NugGet need a different tag/version each time,

• If we bump it to 3.16 instead…

  • we now have to update ALL THE Documents,
  • to mark the previous 3.15 as Broken, …
  • "Bless" the 3.16, …
  • and commit …
  • something WHICH is equivalent to a NEW(!) PROMISE,
  • looping us back to the same tarpit we started from!.

• To conclude, it is the promised version ids, …

• AND the "blessing of releases" within their own sources

• that burdens the release process.

Solution

• The alternative is to let the version-ID to "float" freely & semantically…

• Decoupled from the certification "Blessing", …

• like this:

• We promise version 4.x.x at a rough date,

  • we tag the repo as v4.0.0-alpha.0
  • and start developing …
  • if during development some features & bugfixes require beta-testing, …
  • they are described semantically with bumps in the version-IDs, …
  • which would be an important aid when deciding merge bases & targets.

COMMENT: see another video for the brahching strategy.

• For example, we get here 4.0.0, …

• 4.0.0-alpha.1 and …

• 4.1.0,

• Documents in the sources are edited to describe just the changes of each intermediate release

  • WITHOUT the "RC" or "BETA" specifiers.
  • And that’s important later, for the final release.

• The Version ID of the executable is derrived ONLY from the LATEST git TAG.

• Versions WITH or WITHOUT prerelease specifiers are allowed.

COMMENT: requires a build plugin such as or alternatives

• If Beta Testers prove a "Release Candidate" GOOD for Certification , …
  • a NEW final TAG is added on that commit, in addition to the "RC" one.
• The "blessed" release is specified EXCLUSIVELY in the Wiki release-table & codeu pages, …
  • which are both editable post-factum (like tags).