Re: [D] Define a release schedule for the project [cloudstack]

GitHub user DaanHoogland added a comment to the discussion: Define a release schedule for the project I agree with most of what @weizhouapache says here, except that I think that a new feature should be accepted by an issue or even an open PR as well. nit just the

Re: [D] Define a release schedule for the project [cloudstack]

GitHub user DaanHoogland added a comment to the discussion: Define a release schedule for the project @JoaoJandre I think discussing here is not bad. As long that if a vote is needed it happens on dev@c.a.o. GitHub link:

Re: [D] Define a release schedule for the project [cloudstack]

GitHub user GutoVeronezi added a comment to the discussion: Define a release schedule for the project Personally, I think it can reach more people here; however, I am more interested in having the discussion itself than where it is taking place. I am fine wherever we have the discussion

Re: [D] Define a release schedule for the project [cloudstack]

GitHub user JoaoJandre added a comment to the discussion: Define a release schedule for the project Well, the original discussion was started on the dev mailing list... but it got no traction. That and @DaanHoogland's advice is what led me to create a discussion here. If you want to take

Re: [D] Define a release schedule for the project [cloudstack]

GitHub user DaanHoogland added a comment to the discussion: Define a release schedule for the project I'm afraid @rohityadavcloud has a point here. The user mailing list is not the place it should happen, dev@ is where any decisions should be "coded". That doesn't diqualify this medium as a

Re: [D] Define a release schedule for the project [cloudstack]

GitHub user GutoVeronezi added a comment to the discussion: Define a release schedule for the project And it is happening: https://lists.apache.org/thread/pohvscqqht43ftq3d4nsftpylg6tgxz0 GitHub link: https://github.com/apache/cloudstack/discussions/8970#discussioncomment-9763127 This

Re: [D] Define a release schedule for the project [cloudstack]

GitHub user rohityadavcloud added a comment to the discussion: Define a release schedule for the project "If it didn’t happen on the mailing list, it didn’t happen." https://theapacheway.com/on-list/ GitHub link:

Re: [D] Define a release schedule for the project [cloudstack]

GitHub user weizhouapache added a comment to the discussion: Define a release schedule for the project My 2 cents. Regarding major releases, we do have plan to create 2 major releases (1 LTS, 1 non-LTS) a year. However, it appears nobody is interested in the non-LTS release. Now all recent

Re: [D] Define a release schedule for the project [cloudstack]

GitHub user GutoVeronezi added a comment to the discussion: Define a release schedule for the project Github Discussions is integrated with the users' mailing list; everything that is posted here is also sent by email and vice-versa. This discussion is way wider than the development scope

Re: [D] Define a release schedule for the project [cloudstack]

GitHub user rohityadavcloud edited a comment on the discussion: Define a release schedule for the project Github Discussions isn't the right place to discuss project governance related matters, but may be used for discussions and to build initial consensus; it was enabled only as a platform

Re: [D] Define a release schedule for the project [cloudstack]

GitHub user rohityadavcloud edited a comment on the discussion: Define a release schedule for the project Github Discussions isn't the right place to discuss project governance related matters, but may be used for discussions and to build initial consensus; it was enabled only as a platform

Re: [D] Define a release schedule for the project [cloudstack]

GitHub user rohityadavcloud edited a comment on the discussion: Define a release schedule for the project Github Discussions isn't the right place to discuss project governance related matters, but may be used for discussions and to build initial consensus; it was enabled only as a platform

Re: [D] Define a release schedule for the project [cloudstack]

GitHub user rohityadavcloud edited a comment on the discussion: Define a release schedule for the project Github Discussions isn't the right place to discuss project governance related matters, but may be used for discussions and to build initial consensus; it was enabled only as a platform

Re: [D] Define a release schedule for the project [cloudstack]

GitHub user rohityadavcloud added a comment to the discussion: Define a release schedule for the project Github Discussions isn't the right place to discuss project governance related matters, but may be used for discussions and to build initial consensus; it was enabled only as a platform

Re: [D] Define a release schedule for the project [cloudstack]

GitHub user rohityadavcloud added a comment to the discussion: Define a release schedule for the project I wouldn't consider Openstack volunteer-based project. Two major releases a year, two minor releases a year is something we already aim for but struggle to "ensure" it happens.

Re: [D] Define a release schedule for the project [cloudstack]

GitHub user DaanHoogland added a comment to the discussion: Define a release schedule for the project I like the last sentence of your first point. We still have a 2 releases per year policy though we never make that. As for the second point I think we should reduce out version to a 3 number

Re: [D] Define a release schedule for the project [cloudstack]

GitHub user JoaoJandre edited a comment on the discussion: Define a release schedule for the project @DaanHoogland, about the points you raised: - We have examples of fixed release schedules on volunteer based projects. I think that a great example is OpenStack (see

Re: [D] Define a release schedule for the project [cloudstack]

GitHub user JoaoJandre added a comment to the discussion: Define a release schedule for the project @DaanHoogland, about the points you raised: - We have examples of fixed release schedules on volunteer based projects. I think that a great example is OpenStack (see

Re: [D] Define a release schedule for the project [cloudstack]

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 -

Re: [D] Define a release schedule for the project [cloudstack]

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