He Rene and João, I have opinions about all your points but will not write a long reply to a long mail, which would only discourage people reading either. Maybe we should have a zoom meeting or a dev forum on the next CCC about this?
On Thu, Dec 5, 2024 at 9:28 PM João Jandre <j...@apache.org> wrote: > Hello, René, All > > This discussion has been brought up multiple times this year, and I > totally agree with you, we are due for a new major release. I would > invite you to read the recent threads created about it: > https://lists.apache.org/thread/lh45w55c3jmhm7w2w0xgdvlw78pd4p87, > https://lists.apache.org/thread/4zs8d15ghvvwwro46ry5zjf8fn8x0t88, > https://lists.apache.org/thread/o6o9h3qp8gqrpq4v7o81tl6vp51tkjhg, > https://github.com/apache/cloudstack/discussions/8970 and > https://lists.apache.org/thread/6v0w49gp0fwtp53so757mx6nf34vpg81. > > 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. > > 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. > > Looking at those discussions and Daniel's topics of discussions (see > > https://github.com/apache/cloudstack/discussions/8970#discussioncomment-9754199) > > here would be my proposal: > > 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. > 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. > 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. > 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. > 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. > > Best regards, > > João Jandre > > On 12/5/24 14:20, Rene Moser wrote: > > Dear CloudStack developers > > > > More than 10 years have passed since the release of 4.0.0, and for a > > long time we kept 4 as the major version. The minor version is now at > > 20, but the word ‘minor’ is not correct: each new ‘minor’ version has > > many new features and a lot of work from you has gone into it. That's > > a nice constant in the ever-changing software world! > > > > A few years ago (and I'm not entirely innocent of this) we introduced > > another digit in the version number. I still think, it was and is a > > good decision. > > > > But I wonder how much longer we want to keep this 4? Wouldn't it be > > time (as with the Linux kernel, by the way) to think about increasing > > the major version every few years before we run out of numbers? > > > > Even though there may not be a technical reason, it is a ‘sign’ or > > marketing that the development of CloudStack is progressing. > > > > CloudStack 5! What do you think? > > > > Regards > > René > -- Daan
