Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
I am working on a multi contributor project, having ~2500 Commits. It has multiple components, i.e. Frontend, Backend and Data Processor/DB Ingestion.
Now that we are expecting more contributors, a Versioning System should be implemented, and should be displayed on footer of Frontend, as vA.B.C, where A = Big Change, B = New Features and C = Patch Fix. But, the issue is that we are having a very complex multi component software and has many commits.
How should I approach this?
The semantic versioning is meant to manage the dependencies between components, based on their public API:
Software using Semantic Versioning MUST declare a public API. This API could be declared in the code itself or exist strictly in documentation. However it is done, it should be precise and comprehensive.
The whole versioning logic is building on this public API and the backward (in)compatiblity it offers.
So, in principle:
If you have a single codebase that provides several internal components, you should have a single version number. Changes in private code (and private component API) may lead to minor versions.
If however your codebase provides several components that offer each a public API and that could be deployed independently, it may be a better option to have a different version number for each component. The overall product should then also have its own version, that evolves independently of the component's version.
Note: In the second case, if the components could be deployed independently, why not put them in a distinct repo ? In all cases, if a version is to be displayed in the front-end, display the version of the main product, and offer a possibility to display the also the list of components with their own versions.
