From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 69687 invoked by alias); 25 Jun 2019 19:08:19 -0000 Mailing-List: contact bzip2-devel-help@sourceware.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Subscribe: List-Id: Sender: bzip2-devel-owner@sourceware.org Received: (qmail 69677 invoked by uid 89); 25 Jun 2019 19:08:19 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.100.3 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.3 required=5.0 tests=AWL,BAYES_00,SPF_NEUTRAL autolearn=no version=3.3.1 spammy=provider, dist, HX-Envelope-From:sk:federic, picked X-Spam-Status: No, score=-0.3 required=5.0 tests=AWL,BAYES_00,SPF_NEUTRAL autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on sourceware.org X-Spam-Level: X-HELO: mx1.suse.de X-Virus-Scanned: by amavisd-new at test-mx.suse.de Message-ID: <784d581eb491e4d6a5cb3acc28dd0cd47e49cc33.camel@gnome.org> Subject: Re: Releasing bzip2 1.0.7 and 1.1.0 ? Was: [PATCH] bzip2: Fix return value when combining --test,-t and -q. From: Federico Mena Quintero To: Mark Wielaard , Santiago Ruano =?ISO-8859-1?Q?Rinc=F3n?= Cc: bzip2-devel@sourceware.org, Anibal Monsalve Salazar , Anthony Fok Date: Tue, 01 Jan 2019 00:00:00 -0000 In-Reply-To: References: <1561362056-4393-1-git-send-email-mark@klomp.org> <20190624083116.GN6125@bartik> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.30.4 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-SW-Source: 2019-q2/txt/msg00011.txt.bz2 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