Open Adda0 opened 1 week ago
@kilohsakul @vhavlena @jurajsic @ondrik What do you think about this proposition?
I agree to have a stable master.
Sounds like a good idea, I agree.
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.
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.)
Currently, we merge everything into
devel
with an auto tagging script running after every merged PR. This means that whenever we merge a PR intodevel
, a new tag is created, deployed to PyPI, etc. However, even code merged intodevel
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. Thedevel
will function as it has so far, with the only change being that the auto tagging script will be redirected tomaster
. We will merge PRs intodevel
one by one as they come, anddevel
may introduce breaking changes whenever necessary.master
, on the other hand, will be updated only once in a while, manually, by creating a PR fromdevel
tomaster
, with automatic tagging with proper versioning.master
will serve as the release branch for Mata, which was currently inadvertently served bydevel
.This way, one can:
master
with patch version number bumps.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.