Use master branch for release versions with automatic tagging

[Adda0]

Currently, we merge everything into devel with an auto tagging script running after every merged PR. This means that whenever we merge a PR into devel, a new tag is created, deployed to PyPI, etc. However, even code merged into devel is constantly being updated in such ways which break the backward compatibility. The tagging system is useful for everyone using the library, but in this current form it actually does not work. The quickly iterated on changes break backward compatibility constantly. That means that we either will bump the major version number after every other PR or so (we would have a major version number around 150 or so now, if applied this approach), or, as it is currently, we ignore the semver semantics of the tagging system, and even minor version number introduces compatibility-breaking changes which makes the versions basically meaningless.

I think that Mata is now in a state where we should have a proper devel-master hierarchy of branches. The devel will function as it has so far, with the only change being that the auto tagging script will be redirected to master. We will merge PRs into devel one by one as they come, and devel may introduce breaking changes whenever necessary. master, on the other hand, will be updated only once in a while, manually, by creating a PR from devel to master, with automatic tagging with proper versioning. master will serve as the release branch for Mata, which was currently inadvertently served by devel.

This way, one can:

1. Propagate important bug fixes into master with patch version number bumps.
2. Introduce new interface options (types, methods, classes, functions) with minor version number bumps.
3. Bring compatibility-breaking changes with major version number bumps, whenever a larger portion of the changes which break compatibility is introduced or as needed, but in a single major version number bump. In our case, that would usually be a version bump for each paper on Mata, or a new Noodler version and similar.

Then, projects depending on Mata (Noodler, student works, other researcher's projects, …) can rely on Mata being well-versioned without having to worry about compatibility changes between minor version changes.

This will be immediately useful to everyone, will allow others to actually depend on Mata, and will make it easier to iterate on new features and improvements in isolation on devel without having to worry about breaking anyone's code and projects.

[Adda0]

@kilohsakul @vhavlena @jurajsic @ondrik What do you think about this proposition?

[ondrik]

I agree to have a stable master.

[jurajsic]

Sounds like a good idea, I agree.

[vhavlena]

Well, I have mixed feelings. On the one side the current versioning system is a bit funny, making it more meaningful is a good choice. One the other hand it sounds a bit like it introduces another level of a mess.

[Adda0]

What kind of mess are you thinking about? Everything would be automatic, so the only thing necessary to do manually would be to create a PR from the latest changes on devel from time to time, or when needed (to fix a bug in "production", i.e., a release used somewhere, for example). In case of Noodler, I think we would still keep depending on devel (specific commit), and only really used fixed versions for Noodler when submitting a paper or sending Noodler on a competition ("in this paper, we used Noodler version x.y.z with Mata version xm.ym.zm").

Currently, the only thing that we can reasonably say to a student or a researcher wanting to use Mata is to use Mata version <that specific commit> corresponding to <that tag number>. However, when you use Mata, you cannot update to any versions with higher minor versions, because there is a high chance something will be incompatible. For example, if someone uses Mata in Jupyter notebooks from PyPI, PyPI will update to higher minor versions because it is said to be backward-compatible, but in fact their notebook might not run after the update any more.

(Do not mind the fact that merging a PR from a fork of Mata -- for example from a student's fork of Mata -- will not trigger the tagging script, so the changes in the PR are inaccessible until the next PR from this repo is merged. Which causes a problem that when the next PR from this repo is a small patch, the PR will get merged with the patch version bump. However, the new patch version will also include the breaking changes from the previous PR, completely breaking the versioning even for patches.)

[Adda0]

An alternative approach, since this is a research project whose versions are considered in “generations”, we can adapt a widely-used modification as generation.major.minor (adding generation version number and dropping minor version number, as suggested in a SemVer repo issue). This approach corresponds to SemVer (major.minor.patch) as follows:

• generation is a new version number incremented only when we subjectively decide to release a new iteration of Mata, as in, we publish a new article about Mata, contest in a competition, etc. Or when we substantially rework the main ideas of the project to warrant a new generation (or iteration) to be created.
• major corresponds to SemVer major, only shifted by one to the right.
• minor corresponds to SemVer minor, only shifted by one to the right.
• patch is dropped in favour of generation.

The arguments for and against generation.major.minor are numerous. generation.major.minor is not an ideal solution, as this means that all tools working with SemVer will not work with Mata (will introduce breaking changes to the users of Mata when they try to update Mata). However, generation.major.minor is essentially exactly what we have been doing all this time. The only difference now would be that we would explicitly state that we use generation.major.minor (and anyone doing the actual merging would have to be conscious of this fact).

The way to mitigate the issues with generation.major.minor is to add a section to the project's README.md notifying the user (a student or a researcher) that they should handle releases of Mata in this non-SemVer approach.