search

Project-ARTist / meta

Meta repository for matters related to more than one repository or even the whole project as such.
2 stars 0 forks source link

Versioning #6

Closed schrnz closed 6 years ago

schrnz commented 7 years ago

We currently do not employ any kind of versioning in our projects, but having projects that are not up to date easily leads to incompatibilities, in particular since we are heavily working on all parts. Also, figuring out later which versions in the projects matched at an earlier point in time boils down to comparing commit times, which is a mess.

Introducing proper versioning can solve this problem. It is important to have a versioning scheme that reflects the compatibility between the main parts. I am thinking along the lines of semantic versioning, for example same major and minor version imply perfect compatibility where the patch level only applies to non-breaking changes such as, e.g., small fixes. Finding our what exactly can be derived from, e.g., common major and diverging minor or other combinations is part of this task.

This in general requires some careful consideration since connecting and unifying releases of so many projects with different scopes is an involved task.

Affected Projects

schrnz commented 6 years ago

As indicated above, versioning is a key element in projects with large inter-dependencies, such as ARTist. We are currently looking into how to come up with a versioning scheme that, on the one hand, immediately displays the compatibility with other parts of the ARTist project and, on the other hand, does not require unnecessary version bumps because of weird dependencies.

This is tightly coupled to #3 since the SDK's version will be used to identify whether a module (built against a particular SDK version) will be compatible to the currently available (installed?) version of ARTist.

If anyone is particularly experienced with complicated dependencies among groups of projects, feel free to provide some assistance and feedback.

sweisgerber-dev commented 6 years ago

Your proposed Semantic Versioning (as git tags) along with the classic git-flow should solve all our problems? :)

Develop branches created

Release branches created

Tags/Releases created created

sweisgerber-dev commented 6 years ago

Started setting up develop branches.

schrnz commented 6 years ago

Hey, thanks for joining the discussion. Since it seems I did not specify the focus of this issue enough, I created a dedicated one for discussions about deciding for a branching and release scheme here: #14

schrnz commented 6 years ago

Concerning the versioning problem I tried to outline in the issue, let me clarify.

I want to solve/mitigate the following problem:

ARTist as from the perspective of a user/developer is actually a combination of a version of our art fork, the ARTist code, maybe the ArtistGui deployment app that again uses dexterous, and also multiple modules with their own CodeLibs, ... So I am afraid that we will run into compatibility problems if we implement new features that change multiple projects and hence need updates on multiple ends.

Consider the following example: A new feature in ARTist needs explicit activation via commandline, which needs to be parsed in art (dex2oat.cc) and provided via ArtistGui. If, however, one of the three projects runs on a version that does not include the new feature, everything breaks.

In order to avoid this, I would like the version number(s) of our projects to immediately indicate whether components are compatible.

One of my ideas is to create a dedicated ARTist API (see Project-ARTist/ARTist#11) that is semantically-versioned so that the version number reflects changes to this very API. The modules, however, are compiled against a specific version of the API and hence include an API compatibility number. Following semantic versioning, ArtistGui could automatically decide which modules are still compatible with ARTist versions by comparing those version numbers. ArtistGui could therefore also decide when it can safely upgrade the embedded ARTist version (art & ARTist) so that no modules run into compatibility issues. But this is only the beginning. I will create some kind of overview of the important inter-dependencies between the projects and upload it here soon to better visualize what I am refering to...

sweisgerber-dev commented 6 years ago

Taking the branching model out of scope for the moment

I understood the problems you want to solve, but my answer was much too short, because I wanted to elaborate the details in person.

I totally agree with you, on this matter. While the API is necessary for external modules to be compatible, we also need the different projects to be version-connected.

We could solve the version-connection of the projects problem, either by:

My Choice

In order to fix bugs and keep compatibility for older external modules we probably want to be able to apply hot-fixes to older releases, which is the reason I personally advocate for release branches for each <MAJOR.MINOR> version in combination with tags for bumping the patch version up.

schrnz commented 6 years ago

Alright so @sweisgerber-dev and me discussed this in more detail and came up with the following plan:

The core of Project-ARTist consists of the art & ARTist repos and soon the module-sdk. Those components form a unit that we believe should have one common version number. With https://github.com/Project-ARTist/ARTist/issues/11 we will have a dedicated API for ARTist that contains everything needed for (1) building modules and (2) integrating ARTist into art. We employ semantic versioning on this, i.e., we will increase the patch number for internal changes only (including changes to the signatures of non-api classes and methods), the minor for backwards-compatible changes and the major for non-compatible modifications. Both, art and ARTist, will be tagged with the corresponding version AND the module-sdk will carry this version as well. When building modules, they carry an implicit dependency on the used version of the module-sdk, hence we have the ARTist API version defined above as a compatibility-version in the modules (as metadata).

Other projects like ArtistGui, monkey-troop and the like will have their dedicated, non-connected version numbers. Since they are not considered libraries, we will base the versioning on gut feeling to begin with. In case we need to improve upon this, we can change this at any time. Similarly, dexterous will receive an independent version number, and here we might use semantic versioning since we kind of use it as a library, at least in ArtistGui. Modules are controlled by their respective developers and hence can have any versioning scheme.

For all projects that generate artifacts that we probably serve via GitHub, we will use the versions to tag those in a deterministic manner.