The project contains three libraries (grader service, grader convert, and grader lab extension). Each library relies on the other two, yet the version numbers diverge:
Furthermore, we then bundle these three libraries into a top level "application" called grader service that gets installed with the a helm chart, again with it's own seemingly unrelated version number.
## A chart can be either an 'application' or a 'library' chart.
#
...
appVersion: "0.2.7"
This makes it extremely difficult to create any sort of coherent release plan.
We are essentially operating in a beta release cycle at the moment and not adhering to semantic versioning.
Proposed soluition
Assume that we eventually want our software to be used by humans.
Work towards a stable version 1.0.0, (even if we never get there it might be a useful to observe our code from the perspective of a human being trying to use it).
consolidate version number of the python packages and the helm chart, making it possible to release identifiable versions of the application.
Description
The project contains three libraries (grader service, grader convert, and grader lab extension). Each library relies on the other two, yet the version numbers diverge:
Furthermore, we then bundle these three libraries into a top level "application" called grader service that gets installed with the a helm chart, again with it's own seemingly unrelated version number.
This makes it extremely difficult to create any sort of coherent release plan.
We are essentially operating in a beta release cycle at the moment and not adhering to semantic versioning.
Proposed soluition
Assume that we eventually want our software to be used by humans. Work towards a stable version 1.0.0, (even if we never get there it might be a useful to observe our code from the perspective of a human being trying to use it).