Hi all,
I agree that our current versioning schema doesn't make much sense, as
"minors" introduce pretty big features; even backward incompatibilities
are introduced in minor versions sometimes.
As the current plan is to have 4.20 by June, I think we should stick to
it and still have the next "minor", and make it the last minor version
of the major 4. After so much time in the same major version, we should
plan something relevant before changing it, and June 2024 is a bit of a
tight schedule for that.
I think that we should plan to move to version 5.0.0, we could set the
release date to the end of 2024 or the start (January) of 2025; by doing
that, we have plenty of time for planning and developing amazing
features for version 5, while also preparing a cleanup of our current
APIs. For instance, we are working on the following major developments:
KVM differential snapshots/backups without needing extra software; theme
management system (white label portal for ACS); native snapshot/backup
for VMware (without needing Veeam) to make it similar to what ACS does
with XenServer and KVM; Operators backup (which are different from
end-user backups); and many other items.
What do you guys think?
Best regards,
João Jandre.
On 1/19/24 10:39, Daan Hoogland wrote:
devs, PMC,
as we are closing in on 4.19 I want to propose that we drop the 4. in
our versioning scheme. We've been discussing 5 but no real initiatives
have been taken. Nowadays big features go into our "minor"
dot-releases. In my opinion this warrants promoting those version to
the status of major and dropping the 4..
technically this won't be an issue as 20 > 4 and out upgrade scheme
supports a step like that.
any thoughts?
