[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Releasing bzip2 1.0.7 and 1.1.0 ? Was: [PATCH] bzip2: Fix return value when combining --test,-t and -q.



On Tue, 2019-06-25 at 20:09 +0200, Mark Wielaard wrote:

> With that I think we are ready to do a bzip2 1.0.7 release simply by
> running
> ./prepare-release.sh 1.0.7 and ./update-release.sh 1.0.7.

I like this script!  Thanks for writing it!

> So if the above sounds like a good plan, then we can execute it now.
> Push out bzip2 1.0.7 and put the 1.0.x branch in hibernation, just
> for
> security or major bug fixes. Then we can concentrate on making sure
> that a bzip2 1.1.X (or maybe even call it 2.0?) has a modern build
> system and adds things like O_CLOEXEC support, etc.

I'm sorry for not replying to your mails earlier.  At work they just
moved us to another email provider, and I've had some trouble fixing my
email setup (SMTP servers, etc.) to make everything work as before.

I am... also ready to release 1.0.7 :-P  The work you've done in
updating the release scripts is valuable, and I'd like to propose this
instead:

* Put prepare-release.sh in the gitlab repository, and adjust it for
the changes there.

* Release 1.0.7 from the gitlab repo (it already has the NEWS file with
updates, while I think your repo needs a CHANGES to be written?).  I've
already tested that this works; "ninja dist" takes care of it.

* Keep the soname changes from the gitlab repo.  I think the original
Makefile-libbz2_so is incorrect in how it sets the soname (or at least
libtool thinks so), and both openSUSE and Fedora managed to change it
to a single digit instead of "1.0".  I *think* Debian, and distros
which picked up their patches from there, simply never changed this and
that's why they kept the "1.0" in place.

Whatever we change the soname to, it's going to be incompatible with
some distros - and they are already used to patching things, anyway. 
Maybe purely for my own convenience I'd like to remove the patches from
openSUSE - the current soname in the gitlab repo allows for that.

I would be fine with releasing 1.0.7 from the sourceware repo, and then
a subsequent 1.1 with all the changes from gitlab - but I think this
will cause extra work for the distros.  First they'll have to see which
of their patches need to be removed, and they'll still need to patch
the build system.  And with 1.1 released, they'll need to do it all
over again.

I think we can minimize the work for distros if we update the patches
and the build system in a single release.  They already know how to
handle Meson more or less automatically, while leaving the original
bzip2 Makefiles in place means that each distro has to patch to their
own hand-rolled build system all over again.

[I've sent a few subscribe requests to this mailing list as
federico@gnome.org, but it's not sending me the confirmation mail... do you know who may be able to kick the list software?]

  Federico