Problem Statement: Versioning is a core requirement for many software products. It usually takes the form Major.Minor.patch where the Major is incremented if there are breaking changes from the previous version, the minor is incremented if the changes are backward compatible, and the patch is used to denote mere bug fixes. Yet it varies from system to system and occasionally requires the wheel to be reinvented across components. Instead, if we look at the source control tracking software such as GitHub, we see a much desirable standardization that serves two-fold purposes – enable each version to be uniquely identified and manage the versions to effectively compare changes. Is it possible to offload the versioning to GitHub?
Solution: We ask if the versioning serves the same purpose. For binary dependencies of large software, the versioning holds a different meaning and form than those for text files that are easy to diff without even version. GitHub solves universal versioning and is ubiquitous in its adoption across companies. There is even a translation from Git logs to Semantic Versioning 2.0.0 where the former captures the changes to the versions in a workspace of files while the latter refers to the standardization of convention for the meaning and form used to represent versions. GitVersion is a tool that can translate the individual versions to the semantic versioning. Together with the ability to make unique, universal version, to give every change a version and to bridge the gap to translate those versions to a form acceptable as compliant with Semantic Versioning standards, GitHub seems like a one-stop shop for versioning, tracking and building a management system around changes.
The artifacts that are versioned by Git are mere files. Therefore, any system that utilizes Git to version its changes must export its changes in a set of files that can be checked in and versioned with Git. The workflow to export the artifacts and import those with versioning into the system avoids reinvention, rewrite, inconsistencies and bugs to deal with their artifacts. Git, on the other hand, has been revising its own versioning strategy from where it was using GitFlow and GitHubFlow in version 2 to using configurations in v3. With configurations, many aspects of the versioning can be tweaked while the former versioning strategy did not.
The other approach is to mimic Git’s version strategy into the product that requires versioning. This avoids having the export and import the artifacts as files and works with object stores such as Artifactory. It is especially helpful if the versions are created using md5 since the hashes will appear similar and have a fixed size of 32 characters in length.
The export of data to text files helps track revisions of data. Just like code is revisioned, data can benefit from change capture in a way that is widely accepted.
Conclusion: Versioning is increasingly becoming a commodity requirement that will likely handed over to platforms, services and clouds that take away the onus from projects, organizations and businesses. This technique to use something like Git that is well-known, universal and ubiquitous will help reduce the cost to build and maintain products in much the same way as cloud computing has reduced the onus and ownership for applications from startups.
Reference: https://1drv.ms/w/s!Ashlm-Nw-wnWxUODFr8nsjQ4GeYR?e=8PMCye
Addendum: Elaboration on the specifications required for Semantic Versioning (SemVer)
1. There must be an API for semantic versioning, and it should be public.
2. Version beginning with X.Y.Z must be non-negative and must not contain leading zeros.
3. A versioned package that is released must not allow modifications to package.
4. Zero as value to begin with for major version is permitted only for development.
5. 1.0.0 version defines the public API.
6. x.y.Z must be incremented only when the fixes are backward compatible.
7. x.Y.z must be incremented if new features are introduced, and older ones are deprecated.
8. X.y.z must be incremented if the compatibility is broken.
9. A pre-release version may be appended with a hyphen and a dot separated identifiers.
10. Metadata may be denoted by appending a plus sign and a series of dot separated identifiers.
11. Precedence evaluates major, minor, patch first then pre-release version, and finally the normal version
No comments:
Post a Comment