Use of dynamic dependencies

[MartinSalinas98]

Note: This PR needs to be merged after xmipp-995.

• xmipp3-installer will now be automatically installed with the plugin to ease Xmipp's new installation process.
• Instead of pointing to a specific Xmipp's version (v3.24.0, for example), a new dynamic tag v3 is used, to avoid needing to release a new version of the plugin just because a new release of xmipp was generated. Now releases in the plugin will only be tiggered by changes in the code of the plugin itself, nothing else.

[oierlauzi]

I see that _binTagVersion and _pluginTagVersion are still around with the release name (Oceanus, Poseidon...). With the new semantic versioning, do they still make sense? Even if we give names to major releases, it is possible that plugin-bin names to get out of sync.

[MartinSalinas98]

I see that _binTagVersion and _pluginTagVersion are still around with the release name (Oceanus, Poseidon...). With the new semantic versioning, do they still make sense? Even if we give names to major releases, it is possible that plugin-bin names to get out of sync.

Starting from this new release, the naming also will change, in which way still has to be decided, but it's a minor issue, since it's only something "visual". There are several options:

• Remove the release names completely, leaving only the version numbers. The easiest to do, might release names have some marketing & sentimental value (basically they are kind of cool, but that's all).
• Leave the release names and make a new one for each new release (impractical, as with the new system releases could be generated as quick as in a weekly basis).
• Only add release names to major releases, leaving that name unchanged for all the minor releases of such major. This can cause the name desync between repositories that you mentioned (although I'm not sure that's actually a problem in itself, as the naming convention for the different repositories could just diverge and follow different paths with even different names for the same letter at different points in time), and can also make some names last longer than others, as breaking changes in the codebase can and will occur without an evenly spread development time between them.

In my opinion, we could remove them altogether, as it is the simpler and more trouble-free option, but that's something that requires certain degree of consensus to happen.

[albertmena]

The init.py has to change to launch the xmipp3_installer

[MartinSalinas98]

The init.py has to change to launch the xmipp3_installer

No, it doesn't, as xmipp already calls the installer. From outside xmipp, (that means, when using it either from command line or from the plugin), the installation is done exactly the same way as before.

[oierlauzi]

I see that _binTagVersion and _pluginTagVersion are still around with the release name (Oceanus, Poseidon...). With the new semantic versioning, do they still make sense? Even if we give names to major releases, it is possible that plugin-bin names to get out of sync.

Starting from this new release, the naming also will change, in which way still has to be decided, but it's a minor issue, since it's only something "visual". There are several options:

* Remove the release names completely, leaving only the version numbers. The easiest to do, might release names have some marketing & sentimental value (basically they are kind of cool, but that's all).

* Leave the release names and make a new one for each new release (impractical, as with the new system releases could be generated as quick as in a weekly basis).

* Only add release names to major releases, leaving that name unchanged for all the minor releases of such major. This can cause the name desync between repositories that you mentioned (although I'm not sure that's actually a problem in itself, as the naming convention for the different repositories could just diverge and follow different paths with even different names for the same letter at different points in time), and can also make some names last longer than others, as breaking changes in the codebase can and will occur without an evenly spread development time between them.

In my opinion, we could remove them altogether, as it is the simpler and more trouble-free option, but that's something that requires certain degree of consensus to happen.

I agree. Another possibility would be to only give names to the xmipp (a secas) releases.

[Ratolon]

I see that _binTagVersion and _pluginTagVersion are still around with the release name (Oceanus, Poseidon...). With the new semantic versioning, do they still make sense? Even if we give names to major releases, it is possible that plugin-bin names to get out of sync.

Starting from this new release, the naming also will change, in which way still has to be decided, but it's a minor issue, since it's only something "visual". There are several options:

• Remove the release names completely, leaving only the version numbers. The easiest to do, might release names have some marketing & sentimental value (basically they are kind of cool, but that's all).
• Leave the release names and make a new one for each new release (impractical, as with the new system releases could be generated as quick as in a weekly basis).
• Only add release names to major releases, leaving that name unchanged for all the minor releases of such major. This can cause the name desync between repositories that you mentioned (although I'm not sure that's actually a problem in itself, as the naming convention for the different repositories could just diverge and follow different paths with even different names for the same letter at different points in time), and can also make some names last longer than others, as breaking changes in the codebase can and will occur without an evenly spread development time between them.

In my opinion, we could remove them altogether, as it is the simpler and more trouble-free option, but that's something that requires certain degree of consensus to happen.

I think this option is good, albeit with a previous discussion to define some minor details. It could get us more time to focus on what really matters.

Wbw..M

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud