Re: [Netatalk-admins] Planning the next round of releases

[Daniel M. <mar...@gm...>]

Hi Ralph,

Sounds like a busy time for you! I'm good with ramping up on release
management.
I've been gradually updating and fleshing out the wiki with release
management notes.
Is this fairly comprehensive at this point, or are there any key steps
missing?

https://github.com/Netatalk/netatalk/wiki/Developer-Notes#user-content-Making_a_release

Do you use the standard github web workflow to create the tag, source
packages, and generate the release notes?

Best,
Daniel

On Mon, Apr 24, 2023 at 4:46 PM Ralph Boehme <sl...@sa...> wrote:

> Hi Daniel,
>
> I'm currently at a conference in the US. Next week is going to be quite
> busy and the week after that is SambaXP.
>
> Doing a release is not actually a lot of work, but sitting down and
> taking time is currently difficult as my head is already spinning with
> lots of different stuff I'm managing and working on.
>
> So what I'm trying to say is: maybe it's time you do your first release? :)
>
> Cheers!
> -slow
>
> On 4/18/23 23:23, Daniel Markstedt wrote:
> > Hi Ralph,
> >
> > Just a friendly reminder about this -- for when you have some time to
> > spare to tag the releases!
> > All the pending PRs are strictly optional for the 3.1.15 release. Up to
> > you if you want to merge them now or wait.
> >
> > On Wed, Apr 12, 2023 at 10:40 PM Daniel Markstedt <mar...@gm...
> > <mailto:mar...@gm...>> wrote:
> >
> >     Ralph,
> >
> >     Good idea with the labels. Let's use this moving forward to manage
> >     the patch releases.
> >     I got convinced to not revert the iniparser v4 change.
> >     The author ran a few diffs to make sure no other downstream changes
> >     had been dropped.
> >
> >     Once you've merged the pending PRs I think we're ready to cut a
> >     release for both branches.
> >
> >     Thanks!
> >     Daniel
> >
> >     On Wed, Apr 12, 2023 at 12:57 AM Ralph Boehme <sl...@sa...
> >     <mailto:sl...@sa...>> wrote:
> >
> >         On 4/11/23 23:41, Daniel Markstedt wrote:
> >          > Never mind; I started cherry picking locally on the 3.1
> >         branch and
> >          > recalled that managing / testing yet another branch is too
> >         much of an
> >          > overhead.
> >
> >         yeah, it adds quite some overhead if we cherry-pick.
> >
> >          > The risk of inadvertently breaking something while
> >         cherry picking might
> >          > be even higher.
> >          >
> >          > The one truly risky change, I think, is the iniparser 3.x to
> >         4.x version
> >          > bump, which turned out pretty messily with a bunch of
> >         regressions.
> >          > So perhaps one idea would be to revert those changes, tag the
> >         release,
> >          > and then restore them in preparation for a future release
> >         (3.2.0?)
> >
> >         ok.
> >
> >         What about labeling MRs that are targetted for a point release
> >         with a
> >         label? I've just created the lable "target-release-3.1" for
> >         this. That
> >         way, when a release is immanent, I can quickly see which MRs
> >         might still
> >         be merged and which not.
> >
> >         -slow
> >
>