Hi Jakub On Wed, Mar 27, 2024 at 4:55 PM Jakub Zelenka <bu...@php.net> wrote: > > We actually decided not to do it for 8.3 because it would be just waste of > time to set all PR's with that milestone. The thing is that PR should just > get merged when it's ready and we won't be delaying release because some PR's > in that milestone are not ready so it does not have any meaning.
Thank you, I was unaware that this was a conscious decision. I agree that it's not particularly useful for the next minor version. If they are ready, nothing is blocking a merge to master. > I'm not really sure if there's any point to have non-draft PR's targeting > next major version because they cannot be merged to master until it is > decided the next version will be the major one. So those PR's should be draft > but it might make sense to create milestone for them to show quickly why they > are in draft. Draft PRs that target the next major version can make sense if they are part of an RFC. I generally believe that every RFC should have at least a proof-of-concept. In my experience, the implementation is the only reliable way to reveal conceptual issues. But then again, such RFCs should be in the RFC listing, as mentioned in my previous message. So I agree that there's not a big need to milestones. > So I don't think there is much point in adding 8.4 milestone but 9.0 might be > useful. That sounds reasonable to me, as it shouldn't cost much. Milestones don't need to be complete either, it can be added where it makes sense, for things that might be forgotten otherwise. Ilija
