Subject: Re: [bug#78332] [PATCH 1/1] 005-regular-releases: Initial draft of GCD005 'Regular and efficient releases'.

From: Steve George <[email-masked]>
Date: Thu, 5 Jun 2025 23:34:31 +0100

Hi Olivier

On Thu, Jun 05, 2025 at 04:22:43AM +0000, Olivier Rojon wrote:
(...)
> Z572 <[email-masked]> writes:
> >>> I think we may need to change the name. We used the name staging before
> >>> switching to the team-based process. If we reuse this name, it may cause
> >>> confusion for later users when searching for information.
> >>> 
> >>
> >> No problem, is there something you would favour?
> >>
> >> If not, what about `next-master` to indicate that it's the next
> >> master? If we think that's too generic we could give it a time-based
> >> date `202509-next-master` - meaning it will be merged back in during
> >> September 2025.
> >
> > I don't have any idea, 202509-next-master might be good, I don't know
> > what others think
> 
> I am in favour of a naming scheme which reflects the time it was created.  It might even
> be sufficient to use just a year prefix since we assume there is only one created per year
> (per release).
(...)

Just to make sure it's clear, this is the name for a branch that would be used for 8 weeks where major changes would be held. This is so that we don't destabilise our main branch ahead of a new release. The reason Z572 was concerned about reusing the name 'staging' is that this was previously tried, and this branch became long-lived and it was hard to merge it back into the main branch.

I was trying to think of a name that would imply that this branch would *only* be around for a few weeks. So suggested the month it was merging back in - to prevent it becoming long-lived. I don't think we should call it by the year as that might encourage our previous problem! What do you think, does that make sense?

Thanks,

Steve / Futurile