Skip to content

Conversation

@psafont
Copy link
Member

@psafont psafont commented Feb 4, 2026

This allows to reserve some minor versions for updates in the 8.x release.

I've bumped it to 900 because 800 will make thing difficult if there are more than 7 API changes in case of emergency.

Also related: there have been no "releases" made recently, does the api_version_minor need to be bumped as well? (in ocaml/idl/api_version.ml)

This allows to reserve some minor versions for updates in the 8.x
release.

I've bumped it to 900 because 800 will make thing difficult if there are
more than 7 API changes in case of emergency.

Signed-off-by: Pau Ruiz Safont <pau.safont@vates.tech>
@edwintorok
Copy link
Member

I think the minor API version needs to be bumped, but can be done closer to the release (it'll also require a rebuild of XenCenter).

@edwintorok
Copy link
Member

edwintorok commented Feb 6, 2026

Although I think this shows that we're doing versioning wrong. Instead of leaving a gap on the minor version for future bumps we should start using the patch version (well there is no support for that here, but we should add it).

This also applies elsewhere in the product, such as the XenCenter api_version string, which only has major/minor and might need similar hacks.

If we really can't introduce support for a patch version for some reason then we should have some convenience functions, that leave a predetermined gap, e.g. version_minor_workaround = 0x100 * version_minor + version_patch, but that shouldn't be needed.

@lindig
Copy link
Contributor

lindig commented Feb 9, 2026

It also seems strange to not use the major version. Effectively we are using a single number here.,

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants