I agree with Carsten here. I consider the outside view of JIRA being consistent more important here than to ease the work for committers in those hours while the release vote is ongoing (because every committer should be aware, at least theoretically). Konrad
> On 17. Jan 2024, at 11:14, Carsten Ziegeler <[email protected]> wrote: > > I think there is no perfect solution. We are operating this way for many > years :) which of course doesn't mean there is no room for improvement. > > I think the scenario you describe happened at least once. but it was detected > when the version was released, the jira issue corrected and all was good. > This requires a little care of the release manager. but it really is more a > theoretical issue. We have all the notifications flying around and usually if > you are working on something you know that there is a vote for it going on. > > The Oak way shows a version as released although it is not, and might never > be - which at least in theory can create confusion to users. > > So I prefer potentially confused release managers over potentially confused > users :) > > Regards > Carsten > > On 17.01.2024 11:02, Julian Reschke wrote: >> Hi there, >> the "Release Management" document suggests adding a new (next) release >> should happen after the release vote, and that the release being voted >> on remains "unreleased" in the meantime. >> Doesn't that leave us with a time windos of 72h+ hours in which issue >> tracking in Jira will be extremely ... awkward? What happens if somebody >> resolves an issue and enters the release currently under vote as >> "fixVersion"? >> (In Oak land, we do it the other way around; we create the "next" >> release first, and make the release being voted on as "released" when >> the vote starts). >> Best regards, Julian > > -- > Carsten Ziegeler > Adobe > [email protected]
