From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8063 invoked by alias); 26 Jun 2019 02:22:14 -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 8053 invoked by uid 89); 26 Jun 2019 02:22:14 -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.6 required=5.0 tests=AWL,BAYES_00,SPF_NEUTRAL autolearn=no version=3.3.1 spammy=HX-Languages-Length:2502, HX-Envelope-From:sk:federic, advertise, fetched X-Spam-Status: No, score=-0.6 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: <28b061f6f1e5ea10de587c99b02817036b6f934e.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> <784d581eb491e4d6a5cb3acc28dd0cd47e49cc33.camel@gnome.org> 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/msg00013.txt.bz2 On Wed, 2019-06-26 at 01:04 +0200, Mark Wielaard wrote: > If we are moving things around and have a modern build system it > might > be better to actually remove most of the embedded versions/dates from > the sources and where they are really needed use configure to set > them. > There actually already seems to be a merge request for that: Yes, I want to update that MR tomorrow for the new build stuff. Just today I did it for BZ_VERSION in the header file; I think just the docs are missing the changes from that MR now. > I realize I am probably overly conservative, but I really like to > keep a 1.0.x branch going just for ancient users (I expect the distro > to > switch to a more modern release, once they figure out the SONAME > thingy). And if we have that ancient branch, where we can just put > security fixes on, and nothing else, then we can be even more > creative on the new modern 1.1.x (2.0.x?) branch. I like this idea more and more. And now I feel sheepish, because it's basically the same approach I took for librsvg 2.40.20, the last C version without Rust code in it. This is from that version's release notes: Version 2.40.20 - Except for emergencies, this will be the LAST RELEASE of the librsvg-2.40.x series. We are moving to 2.41, which is vastly improved over the 2.40 series. The API/ABI there remain unchaged, so we strongly encourage you to upgrade your sources and binaries to librsvg-2.41.x. I fetched from the sourceware repo onto my gitlab repo to see the changes, and indeed the sources are practically identical (the build stuff and docs are of course changed). What do you think of me doing this: - Create a "bzip2-1.0" branch with the commits and contents of the sourceware repo. - Sync the sources? Are there any changes in the gitlab master branch that you *don't* want? - Release 1.0.7 out of the bzip2-1.0 branch; deprecate that branch immediately. Advertise it as targeting people who embed bzip2-1.0.6 in their sources and probably already have customizations to the build system themselves. - Continue with the current development in the master branch; I'll probably release 1.1.0 as an experimental release with the new build stuff and all the fixes. Advertise this as targeted to distros and everything else. - Rust goes in a separate branch as usual; it's going to need some big changes to the new build system anyway. Federico