-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Move to semver versioning for MO2. #154
Conversation
As it's not super clear from the PR description, are we planning on treating the 2 in MO2 as the semver major version, and having MO3 the next time there's a breaking change to the plugin API, having the 5 in MO2 2.5.x be the semver major version and having MO2 2.6 the next time there's a breaking change to the plugin API, or something else? |
The changes is more about enforcing the semver syntax on versions (for MO2, and for extensions in the future) rather than to enforce the actual major/minor/patch semantic, although if we go that way, I'd say that minor would be breaking changes and patch bug fix. |
Does this have any chance of breaking version migration code? We have code that compares current version and previously installed version to determine whether some version migration code needs to be executed. |
The migration code actually uses I tested the changes with various MO2 version by modifying the MO2 uses its own version string, which are not semver compliant, so what I did is add a custom parser for those - you can see there is a You can also check the other PR ModOrganizer2/modorganizer#2063 |
The only changes from a user/"behavior" point-of-view would be the display of the version for users, but only for non-final releases. Before it would have been |
I have changed the PR to allow a "subpatch" in the versions, so that 2.2.2.1 would not be considered a pre-release of 2.2.2. This should only be used for MO2. I updated the comment of the I also added configurations for the |
996e6b6
to
8f83d73
Compare
…ring pre-releases.
This PR adds functions related to Semantic Version parsing/comparing to
uibase
(https://semver.org/).Why?
I started working on this for extensions but in the end I feel like this can be integrated sooner, hence the PR.
To me the current
VersionInfo
is very flawed, and hard to work with, moving to a more streamlined versioning scheme will probably help further development.The goal is not to follow directly the semver scheme of major/minor/patch for breaking changes, etc., but rather to have a streamlined and specified way of parsing/presenting and comparing versions.
Impact?
This should have little impact on code and user-experience, aside from MO2 itself (I will make a corresponding PR) -
Version
object - the oldappVersion()
method fromIOrganizer
will simply be deprecated but the underlying implementation will actually useversion()
.Note: This also changes the layout structure of code in VS because the flat layout was getting a bit hard to navigate. I did not feel like making a separate PR for it.