Add dynamically updated major version tag #223
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
oierlauzi
approved these changes
Mar 17, 2025
Collaborator
oierlauzi
left a comment
oierlauzi
left a comment
There was a problem hiding this comment.
I have no way of testing this, but LGTM
albertmena
added a commit
to I2PC/xmipp3
that referenced
this pull request
Nov 17, 2025
## **Note: This PR needs to be merged after [xmippCore-223](I2PC/xmippCore#223) and [xmippViz-73](I2PC/xmippViz#73 The new installer is located in [this repository](https://github.com/I2PC/xmipp3-installer). ## Changes This greadtly simplifies the code complexity of the installer in this repository, and allows it to evolve at different rates, being able to fix issues or extend the installer capabilities without relying on making releases of Xmipp. With that change, comes a new paradigm on how source dependencies are handled in xmipp (xmippViz/xmippCore/scipion-em-xmipp): - scipion-em-xmipp will no longer be automatically installed by xmipp. This is because the plugin depends on xmipp, not the other way around, so the plugin must be the one installing xmipp (in production only). - xmippCore & xmippViz are still installed by the installer of xmipp, but now, instead of cloning specific fixed versions (for example, `v3.24.0`), it will do so with a dynamically updated tag pointing to the latest major release of such dependency (for example, `v3`, which match the content of the latest `v3.X.Y` release). ## New release paradigm This change enables skipping the release process in sources that don't actually need it, and that it was happening until now because of a simple update in the dependency number. Now that release cascade will only be needed if a major release happens. ### Example of how it was until now (with any kind of release): - `xmippCore`, `xmippViz`, `xmipp` and `scipion-em-xmipp` are all in version `v3.24.0` initially. - `xmippCore` creates release `v3.25.0`. - `xmipp` needs to create release `v3.25.0` to update the version to be downloaded of `xmippCore`, from `v3.24.0` to `v3.25.0`. - `scipion-em-xmipp` needs to do the same thing to retrieve the latest release of `xmipp`. ### With the new process (minor or patch release): - `xmippCore`, `xmippViz`, `xmipp` and `scipion-em-xmipp` are all in version `v3.24.0` initially. - `xmippCore` creates release `v3.25.0`. - Tag `v3` of `xmippCore` is updated to match the content of tag `v3.25.0`. - `xmipp` is pointing to release `v3`, so, whenever a new install is triggered, it will already automatically download the newest version of `xmippCore`, so no changes are required in `xmipp`'s side. - `scipion-em-xmipp` also does not need to create a new release. ### With the new process (major release): - `xmippCore`, `xmippViz`, `xmipp` and `scipion-em-xmipp` are all in version `v3.24.0` initially. - `xmippCore` creates release `v4.0.0`. - Tag `v4 of `xmippCore` is created. It matches the content of tag `v4.0.0`. - `xmipp v3.24.0` is currently pointing at `xmippCore v3`, so, this version will not be affected by the breaking changes introduced in the `v4.0.0` release of `xmippCore`. To point to that new major release, version `v3.24.1` can be created. This new version does not need to be a new major (`v4.0.0`) since `xmipp` itself is not breaking any compatibility towards its programs (in other words, `scipion-em-xmipp` can still use the same `xmipp` programs without any code changes). - When the new `v3.24.1` release is created, tag `v3` in `xmipp` will be updated to match its content. - `scipion-em-xmipp` does not need to implement any code changes, and, therefore, no new release is needed. ## Conclusion The improvements described above allow to generate more frequent releases, with new functionality and bug fixes. As the pipeline process of a release only takes ~5-10 minutes combined (adding up release times of all xmipp sources & the plugin), the releases can be as frequent as the development team wants, allowing users to experience almost inmediately the newest develpments and patches, instead of needing to wait ~6 months for each release. --------- Co-authored-by: alberto <alber.mena@gmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a tag with the name of the latest major version, that will automatically be updated with every new release.
For example, if the latest tag is
v3.24.0, a tagv3will be created with the same content ofv3.24.0.If then, tag
v3.24.0.1is released, tagv3will be automatically updated so that its content matches the one of the newly created tag.If tag
v4.0.0is created, a new tagv4will be generated as a new major release.This will allow cloning
v3tag to automatically get the latest release within major version 3, and so on, allowing an easy way of handling dependency updates without triggering releases in repositories that depend on this one.