Hi João
This goes a bit further than my cosmetic "let us change the major
version to 5" but I have to agree that our "change set per release" is
not reflected in the "version number scheme".
Maybe I'm the wrong person to ask about changing the release process, or
how we implement features because I've not been active lately and never
volunteered to be an RM and have no intention of doing so. I also have
no idea how much work it is to create a new version, but I would imagine
that a release manager would be more than relieved to know that we can
and should break APIs in major version to make the software even better.
On 05.12.24 21:28, João Jandre wrote:
From the marketing side, it's clear to me that operators are confused
by this lack of direction of the project, with no major versions for 10
years, an outsider may think that the project is dead or extremely
stable, both of which are false: we introduce plenty of new features and
there is much work to be done still. Moreover, it hurts the project to
have minor versions which break compatibility.
So, I don't think outsiders would see the project as dead at all BUT
maybe it may look very conservative in development (which it isn't).
Speaking of breaking changes as a API client software developer, I can
provide a list of things I had to implement to workaround API changes
after minor releases for the Ansible Cloudstack ... API changes are per
definition breaking so belongs to major.
I love code refactorings to cleanup and breaking things but only in majors.
Furthermore, we have plenty of technical reasons to do so. I'll repeat
below my view on this topic, as I posted on the last thread about it:
I think we should really sit down and discuss the direction that we want
to bring the project. We should build a consensus on a versioning schema
that will come with the proper mechanisms of deprecating/removing
features, as well as introducing breaking changes.
Ack
1. **Looking at our history, what would be the ideal cadence of major
releases for our context and why?** On average, we take 9 months to
release a new minor version. Considering that our 'minor' versions are
where our major changes happen, we could take this cadence of minor
versions and transfer it into major ones. Furthermore, as we will have
mechanisms to introduce breaking changes (and those tend to take time),
we should add some padding on those 9 months and make it 1 year. We also
do not need to decide on a specific month to release the version, we
could have a quarter (Q1/Q2/Q3/Q4) that is when the version is scheduled
to release. That way, we will have some predictability on when the
release is out, but also some flexibility.
I would even want take the pressure off and not set a fixed release
schedule, but make an estimate. Some major releases may take longer,
some shorter, but an average of 9 to 15 months would be desirable.
2. **How and when should we define the RM for each major?** For the
'how', I like the current system of someone volunteering and the
community voting on them; I don't see any reason to change this. As for
the 'when', the week following a new release, we should already have a
new RM to guide the next one. This way, we avoid having an aimless
project for too long.
okay.
3. **How should we introduce disruptive changes and remove
compatibility?** For our first major release, I think we should announce
these changes as soon as the discussions about versioning are over and
introduce these changes on that release. But for the future, the better
method would be: on one major release, we announce the disruptive
changes and deprecate the necessary code; on the next one we introduce
the changes.
Other big software projects have process for that: proposal enhancement
process, e.g. KEPs [1] or PEP [2].
It doesn't need to be done (or enforced) for every little thing but for
breaking things and general rules and processes (e.g. release process)
and changes of these rules and processes would be desirable and helpful
indeed.
4. **What are the community's common goals?** From our discussions, it
seems like a part of the community wants to keep the project as is and
not introduce too many breaking changes. However, we also have another
part of the community that wants to evolve the project and try to make
it even better. As always with a community we should strive to build a
consensus on changes, if they should or not happen. We could have an
annual discussion planned to map what are the next year's goals, as well
as decide on things that should not change (at least at the time). This
discussion could be held at the start of a new major release cycle so
that the RM has a north to follow and steer the community efforts. I
think that one common goal that we should try to achieve is the creation
of an automated release process. We could create a pipeline that does
most (or all) the release process so that we only have to approve it
(and tweak it if needed) before releasing.
Classic Admins vs. Devs. As a admin, I want to minimize risk during
upgrades (minor upgrading won't break things) as a dev I want to break
things more often.
But we could have both and should have, otherwise we one group will turn
away. So a versioning system that more accurately reflects the risk of
upgrades would be desirable.
5. **Regarding minor releases, should we flexibilize it more or be more
rigid?** I think we should concentrate our big and new features on the
major versions; while tweaks and bug fixes would go on the minor
releases. This way, we can have more stable minor releases that do not
introduce too much stuff at a time. Focusing on the major releases for
new features will allow us to better test them and do better quality
control.
I more than agree.
Overall I would love to help to implement such a process and let devs
break things on purpose in majors and keeps the admins calm giving them
more stable software in minor and bugfix releases. So a Win-Win.
René
[1] https://www.kubernetes.dev/resources/keps/
[2] https://peps.python.org/
