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

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

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...> 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
>
>