GitHub user DaanHoogland added a comment to the discussion: Define a release schedule for the project
@GutoVeronezi points to the more abstract reasons we want to allow breaking changes. We have long had a list of more mondain reasons to introduce breaking changes: - API truly restful - ORM/DAOs upgradable per feature PR instead of per version - agent API more consistent with state of the art json frameworks. - ... and the discussion will coming back. (thanks for pointing to one of the threads that highlighted this @GutoVeronezi ) On one hand, I think some of these can be introduced without breaking as well. APIs can be running alongside of each other and be slowly phased out. On the other hand, I'd love to have the luxury to break stuff and rebuild it, but works needs to get done. The custom DAO framework we maintain will be a pain to get rid of. As to @JoaoJandre 's proposal: - A fixed release schedule; I think this is not feasible in a volunteer based project. Company priorities will get in the way. We can however set a guideline for LTS branches that for instance 10+ PRs/fixes warrant a release (we now do 200+ usually, so just being arbitrary) - A mechanism to introduce disruptive changes; Yes, we should allow for that and help users on a consultancy basis if they want to migrate. (still think we should drop the 4 yesterday) GitHub link: https://github.com/apache/cloudstack/discussions/8970#discussioncomment-9222753 ---- This is an automatically sent email for users@cloudstack.apache.org. To unsubscribe, please send an email to: users-unsubscr...@cloudstack.apache.org
