Updating version numbers for release 24.0.0-SNAPSHOT

[wido]

Description

Following the [VOTE] "Version naming: drop the "4." prefix starting with release 24" on dev@cloudstack.apache.org, started on 14 August 2026 and closed on 21 August 2026 at 12:00 UTC, the release that would have been 4.24 is released as 24, i.e. 24.0.0. Subsequent feature releases become 25, 26, and so on, and maintenance releases on the 24 branch become 24.1.0, 24.2.0, and so on.

The vote passed by lazy majority with 4 binding +1 votes (Wido den Hollander, Daan Hoogland, Kiran Chavala, Vishesh Jindal), 1 non-binding +1 (Simon Weller), 1 +0 (Abhishek) and 1 -1 (Joao Jandre Paraquetti).

This changes the version only, touching the same files that tools/build/setnextversion.sh does:

• in all pom.xml files
• debian/changelog
• tools/marvin/setup.py
• tools/docker/Dockerfile, Dockerfile.marvin and Dockerfile.s390x

The leading "4." has not carried any meaning for many years. Dropping it does not affect the release cadence, the LTS policy, the branching and release process or the backwards-compatibility guarantees, and it is not a signal that 24 breaks APIs or introduces disruptive changes.

org.apache.cloudstack.utils.CloudStackVersion already parses and compares both three and four position versions, normalising 24.0.0 to 24.0.0.0, so 24.0.0 still compares greater than 4.23.0.0.

Vote thread:
http://www.mail-archive.com/dev@cloudstack.apache.org/msg107393.html

Types of changes

• Breaking change (fix or feature that would cause existing functionality to change)
• New feature (non-breaking change which adds functionality)
• Bug fix (non-breaking change which fixes an issue)
• Enhancement (improves an existing feature and functionality)
• Cleanup (Code refactoring and cleanup, that may add test cases)
• Build/CI
• Test (unit or integration test code)

Feature/Enhancement Scale or Bug Severity

Feature/Enhancement Scale

• Major
• Minor

Bug Severity

• BLOCKER
• Critical
• Major
• Minor
• Trivial

Screenshots (if appropriate):

How Has This Been Tested?

Local builds have been run, all compiles

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 3.53%. Comparing base (3d70ce4) to head (3d31a93).
⚠️ Report is 3 commits behind head on main.

Additional details and impacted files

@@          Coverage Diff           @@
##            main   #14041   +/-   ##
======================================
  Coverage   3.53%    3.53%           
======================================
  Files        487      487           
  Lines      41863    41863           
  Branches    7912     7912           
======================================
  Hits        1479     1479           
  Misses     40170    40170           
  Partials     214      214           

Flag	Coverage Δ
uitests	3.53% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[DaanHoogland]

clgtm

[nvazquez]

Thanks @wido - largely looks good. Just a question, are we keeping the schema upgrade SQL path files named as before or those should also be updated?

[Pearl1594]

Most changes have been taken care of.
Just wondering if we also need to look at the ci workflow here: https://github.com/apache/cloudstack/blob/main/.github/workflows/docker-cloudstack-simulator.yml#L24-L26 - it only triggers the docker image build on tags matching 4.* / 5.*, so once we start tagging releases as 24.0.0 etc, this workflow won't pick it up and the image build would just silently not run.

Also, since we've been following the 4.x naming for several years, its pretty likely contributors may keep writing since = "4.24.0" out of muscle memory despite this being communicated. Do you think it makes sense / would help to add a pre-commit hook to catch that automatically instead of relying on reviewers to spot it every time? This could be done on a separate PR too - we could add the hook to .pre-commit-config.yaml