Using milestones and selecting the earliest release where an issue will
land sounds good to me. For planning purposes we generally want to know
what is the oldest branch a change should land in and milestones work
perfectly for this.
For retrospective purposes milestones are not perfect, however
On Wed, Jul 3, 2024 at 5:37 PM Dave Marion wrote:
>
> Comments inline.
>
> On Wed, Jul 3, 2024 at 4:33 PM Christopher wrote:
>
> > I think you are proposing a single "2.1.3" issue, for example, whose
> > body somewhere (top comment, perhaps) is manually updated as one big
> > massive list of link
Comments inline.
On Wed, Jul 3, 2024 at 4:33 PM Christopher wrote:
> I think you are proposing a single "2.1.3" issue, for example, whose
> body somewhere (top comment, perhaps) is manually updated as one big
> massive list of links to all the issues/PRs for that release?
Yes, although I'm not
I think you are proposing a single "2.1.3" issue, for example, whose
body somewhere (top comment, perhaps) is manually updated as one big
massive list of links to all the issues/PRs for that release? That
sounds like a nightmare to maintain, impossible to enforce consistent
use, and extremely unlik
Another option would be to do it manually by creating an issue where the
top comment is a checklist of all the related items in that release. Much
like the post-vote release checklist[1] issues that we have. Yes, this
means that the developer is going to have to update some other number of
tickets
No objections from me, I am +1 for going with the single milestone approach
as it seems like the best way for now unless Github makes improvements.
On Tue, Jul 2, 2024 at 7:05 PM Christopher wrote:
> Hi Accumulo Devs,
>
> I wanted to bring to everybody's attention that GitHub is sunsetting
> the
