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

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

Release tagged and tarballs rolled:
https://github.com/Netatalk/netatalk/releases/tag/netatalk-3-1-15

I'll run some more tests and then send the official announcement later
today or tomorrow.

FYI, I didn't cherry pick the "Regenerate sparql_parser" change since
it inadvertently added a dependency
on yacc / bison (at least on Debian Bookworm).
I also skipped the ABI check removal. Seemed unnecessary for a patch release.

On Thu, Apr 27, 2023 at 11:05 PM Daniel Markstedt <mar...@gm...> wrote:
>
> Found a temporary hotfix until I figure out how to properly modernize
> configure.ac
> - https://github.com/Netatalk/netatalk/pull/330
>
> The good news is that since we have 'make check' running in github CI,
> a breakage such as this will be caught early in the future. :)
>
> On Thu, Apr 27, 2023 at 10:03 PM Daniel Markstedt <mar...@gm...> wrote:
> >
> > the admins ML had inadvertently fallen of the recipient list
> >
> > On Thu, Apr 27, 2023 at 10:02 PM Daniel Markstedt <mar...@gm...> wrote:
> > >
> > > > That's how I used to do it in the past as well. Plus requiring a
> > > > bugreport or github issue associated with changes targetted at a
> > > > release. Ideally requiring commits to include a reference to the issue
> > > > link in the commit message.
> > >
> > > Yes, I'll consider reintroducing a bit more structure moving forward.
> > > I can see how it helps when managing the changeset for patch releases.
> > >
> > > Anyhow, I've prepared a local branch with cherry picked commits for
> > > the 3.1.15 release.
> > > However make distcheck is failing so I need to dig into what's going on.
> > > Seems to be the same issue as https://github.com/Netatalk/netatalk/issues/313
> > >
> > > make[4]: *** No rule to make target 'test-afp_dsi.o', needed by
> > > 'afp_dtrace.o'.  Stop.
> > > make[4]: Leaving directory
> > > '/home/dmark/netatalk/netatalk-3.1.15/_build/sub/test/afpd'
> > > make[3]: *** [Makefile:1751: check-am] Error 2
> > > make[3]: Leaving directory
> > > '/home/dmark/netatalk/netatalk-3.1.15/_build/sub/test/afpd'
> > > make[2]: *** [Makefile:472: check-recursive] Error 1
> > > make[2]: Leaving directory
> > > '/home/dmark/netatalk/netatalk-3.1.15/_build/sub/test'
> > > make[1]: *** [Makefile:531: check-recursive] Error 1
> > > make[1]: Leaving directory '/home/dmark/netatalk/netatalk-3.1.15/_build/sub'
> > > make: *** [Makefile:748: distcheck] Error 1
> > >
> > > On Thu, Apr 27, 2023 at 10:13 AM Ralph Boehme <sl...@sa...> wrote:
> > > >
> > > > On 4/27/23 10:48, Daniel Markstedt wrote:
> > > > > I tried that and ended up dealing with never ending merge conflicts of
> > > > > 10+ year old NEWS and VERSION updates for some reason.
> > > > >
> > > > > Should I be doing a different command than "git rebase main" from the
> > > > > 3-1 branch?
> > > >
> > > > $ git checkout main
> > > > $ git rebase -i branch-netatalk3-1
> > > >
> > > > ...and in the editor remove all commits from master you don't want, only
> > > > keeping the changes you want in the 3-1 branch.
> > > >
> > > > >> Otherwise, if you want to rethink our branching and release strategy,
> > > > >> the way we do it in Samba is explicit cherry-picking from master to the
> > > > >> release branches for changes that should be part of a release.
> > > > >
> > > > > Yeah I may go ahead and do the cherry-pick approach this time...
> > > >
> > > > That's how I used to do it in the past as well. Plus requiring a
> > > > bugreport or github issue associated with changes targetted at a
> > > > release. Ideally requiring commits to include a reference to the issue
> > > > link in the commit message.
> > > >