New releases for bugfixes
Harald Sitter
sitter at kde.org
Wed Sep 7 11:15:47 BST 2022
That'd undermine the entire point of knowing that in order to have
bugfixes 1, 2, 3 the user first needs to have version 567 not 566
I imagine a world where we could simply have the versions be w.x.y.z
to begin with
On Wed, Sep 7, 2022 at 7:58 AM Tobias C. Berner <tcberner at freebsd.org> wrote:
>
> On Tue, 6 Sept 2022 at 23:46, Antonio Rojas <arojas at archlinux.org> wrote:
> >
> > El viernes, 26 de agosto de 2022 11:27:16 (CEST) Adriaan de Groot escribió:
> > > On Friday, 26 August 2022 01:35:55 CEST Ahmad Samir wrote:
> > > > From a packager's point of view, I think it is the same amount of work to
> > > > grab a commit from upstream git and rebuild a package or to package a new
> > > > point release.
> > >
> > > For FreeBSD things, it works like this:
> >
> > > At the point of the patch / bugfix release, the amount of work is about the
> > > same: edit one or two lines, build, done. But having multiple tweaks out
> > > there, and different versions of tarballs while **also** having regular
> > > "everything is back in version-number-sync now" releases is administratively
> > > more complicated.
> > >
> >
> > I have to agree here - from my packaging POV using tarballs that deviate from the general versioning scheme makes things harder as it will cause conflicts with our packaging scripts. So I would appreciate if next to these tarballs we still get a list of commits so distros can decide whether they want to use tarballs or backports.
>
> +1
>
> >
> >
> >
> >
More information about the Distributions
mailing list