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
[wiki](https://cwiki.apache
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:
https://github.com/apache/cloudstack/discussions/8970#discussioncommen
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 phase
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 this
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 g
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
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:
https://github.com/apache/cloudstack/discussions/8970#discussioncomment-9759446
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 m
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 (as
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 t
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 t
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 t
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 t
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 to
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.
Practicall
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
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 https://releases.openstack
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 https://releases.openstack.
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/DA
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 importa
20 matches
Mail list logo