+1 on what Pearl said. ACS's adoption is increasing extremely fast, I've never heard of any potential or current operators having any issues with the versioning number (I definitely didn't when operating ACS from 4.1 up to 4.15).
-----Original Message----- From: Pearl d'Silva <pearl.dsi...@shapeblue.com> Sent: 10 December 2024 05:06 To: dev@cloudstack.apache.org Subject: Re: CloudStack 5? Hi, I wouldn't say that our current release naming strategy in anyway gives the wider community and consumers the idea that this project is dead or stagnating. There has been an increase in adoption, that said, I do not oppose renaming the upcoming release to CloudStack 5 or anything else for that matter. And I think this would be the right time to at least start some work on it, as it would give us time to evaluate if there are any major blockers. The end goal of this effort should be to maintain the stability of the project and ensure no regressions. Whatever naming convention we choose to adopt would however definitely require marketing effort. Regards, Pearl ________________________________ From: Bernardo De Marco Gonçalves <bernardomg2...@gmail.com> Sent: December 9, 2024 12:19 PM To: dev@cloudstack.apache.org <dev@cloudstack.apache.org> Subject: Re: CloudStack 5? Hello all, Thanks Rene for raising this discussion once again. As João has previously mentioned, there are numerous technical reasons for establishing a defined release process for the project. In my opinion, the key points to address here are the scope of changes for each version type (major, minor, and patch) and the need for a predictable and reliable release schedule for CloudStack. Regarding the scope of changes, it is well-known that CloudStack uses legacy technologies, libraries, and dependencies. Additionally, there are several plugins and APIs that could be trimmed from the codebase; the persistence layer could be replaced by modern ORMs; the API's architectures could be standardized to address the REST pattern; and lots of other changes could be made. These kinds of changes are crucial for maintaining the project's long-term health, as it also helps in reducing the barriers for new contributors, which is vital for promoting innovation and introducing new features. However, currently it's not feasible to introduce such big changes, since our major versions are supposed to not accept compatibility breaking changes. Therefore, defining the scope and objectives for each type of release would definitely help enhance the project's predictability and reliability for users and operators. Regarding the release schedule, I believe adopting a time-based release management protocol is essential. When analyzing the history of major CloudStack releases since 4.10 [1], it's clear that the schedule lacks consistency. Some major releases were completed within six to eight months, while others took approximately a year or more. So, it appears that we have been adopting a feature-based strategy rather than a time-based one. In my view, adopting a well-defined time-based release management protocol would also help enhancing the project's reliability. It would provide a consistent reference point for users, operators, and developers, allow sufficient time for proper testing of new features, and eliminate the need to rush the merging of pull requests. It's important to note that a time-based release strategy doesn't need to be extremely rigid, as seen in some open-source projects. Considering that, I agree with João's proposal. Finally, I'd like to recommend the reading of this paper [2] that evaluates the implementation of a time-based release management strategy on open-source projects. Best regards, Bernardo De Marco Gonçalves (bernardodemarco) [1]: https://github.com/apache/cloudstack/discussions/8970#discussioncomment-9754199 [2]: Brian Fitzgerald, Martin Michlmayr: Time-Based Release Management in Free/Open Source (FOSS) Projects. Available at: https://lero.ie/sites/default/files/Lero-TR-2011-04.pdf Em sex., 6 de dez. de 2024 às 05:02, Rene Moser <m...@renemoser.net> escreveu: > 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/ >
