You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
should we stick to Git's versioning scheme or are we free to diverge now that we are out of tree? presumably we'd want to make releases here, what should the be called/numbered?
What I would propose is that we try to follow git major version numbers and stick to semver for the rest. so we could start with 2.15.0 to show where we diverged from and take it from here.
(this, of course, assumes we won't break API compatibility ourselves, which would force us to break major version number tracking with git, which would break this assumption... but maybe we don't mind that either.)
The text was updated successfully, but these errors were encountered:
What I would propose is that we try to follow git major version numbers and stick to semver for the rest. so we could start with 2.15.0 to show where we diverged from and take it from here.
OK with that. At some point in the past we were tied rather closely to Git because improvements to Git-Mediawiki were often coupled with a fix/patch on the Git side, but I don't foresee such thing happening often in the future so it should be sufficient to just mention somewhere "requires Git >= x.y.z" (so no need to try to synchronize version numbers). Even synchronizing with Git's major version may not be necessary (but we don't have to decide this now, we can just wait for Git 3.0 to come and it may well end-up being a dummy "major version" like Linux 3.0 and 4.0).
should we stick to Git's versioning scheme or are we free to diverge now that we are out of tree? presumably we'd want to make releases here, what should the be called/numbered?
What I would propose is that we try to follow git major version numbers and stick to semver for the rest. so we could start with 2.15.0 to show where we diverged from and take it from here.
(this, of course, assumes we won't break API compatibility ourselves, which would force us to break major version number tracking with git, which would break this assumption... but maybe we don't mind that either.)
The text was updated successfully, but these errors were encountered: