GitHub user GutoVeronezi added a comment to the discussion: Define a release schedule for the project
Hello guys, Thanks @JoaoJandre for raising the discussion. Many might understand the benefits and the necessity of having a well-defined versioning schema; however, I feel that it is important to highlight the "why" before discussing the "how". We (the community) have a culture of generating code without breaking compatibility. At first look, this may seem interesting as there is an intention to guarantee the continuity of the ecosystem. However, along with that, there is also a tie with old and deprecated procedures, technologies, libraries, and models, which, in the long term, will also deprecate CloudStack and make it more costly to innovate and evolve. We have to understand that we have several development barriers. We are already working with a highly complex context; to work with CloudStack, developers need to understand storage, networking, virtualization, Internet protocols, and much more. On top of that we do not use mainstream/standardized frameworks for the RESTful APIs and JPA; we use Spring in a non-standard fashion; we do not have a solid standard between our APIs, and so on. We are constantly increasing the complexity to extend/evolve and maintain ACS. That creates a bubble of development where it is hard to join, which is not healthy for a community. All those development fronts mentioned require a lot of effort and investment to get addressed and will certainly generate incompatibility at some point. However, we do not have a well-defined protocol to address incompatibilities nor to release new versions; we have been on version 4 since 2012 and our minor release cadence has been sporadic since then. Knowing that a lot of effort and investment is required to make CloudStack compliant with new and modern standards and frameworks, and our versioning schema is not foreseeable nor addresses introducing incompatibilities between versions, would a contributor or company feel safe to sponsor and put efforts into such changes? Unfortunately, the answer is no. With that being said, by structuring a versioning schema, we can provide previsibility for the project and the community. We would know when to introduce breaking changes, and the community would be expecting them. Furthermore, we can look at how other projects, like OpenStack and GitLab, introduce breaking changes in two steps (deprecation on one major release and removal on another) to reduce their impact on the community. Moreover, we already had a discussion in the past about the same topic; thus, I invite you to check that discussion too: https://lists.apache.org/thread/lwlxs8xgz4glocctf7dv89k5nqqsxmlb GitHub link: https://github.com/apache/cloudstack/discussions/8970#discussioncomment-9214264 ---- This is an automatically sent email for users@cloudstack.apache.org. To unsubscribe, please send an email to: users-unsubscr...@cloudstack.apache.org
