From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 103939 invoked by alias); 25 Jun 2019 18:09:52 -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 103928 invoked by uid 89); 25 Jun 2019 18:09:51 -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=-6.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 spammy=UD:X, website X-Spam-Status: No, score=-6.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on sourceware.org X-Spam-Level: X-HELO: gnu.wildebeest.org Message-ID: Subject: Re: Releasing bzip2 1.0.7 and 1.1.0 ? Was: [PATCH] bzip2: Fix return value when combining --test,-t and -q. From: Mark Wielaard To: Santiago Ruano =?ISO-8859-1?Q?Rinc=F3n?= Cc: bzip2-devel@sourceware.org, Anibal Monsalve Salazar , Anthony Fok , Federico Mena Quintero 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" Content-Transfer-Encoding: quoted-printable X-Mailer: Evolution 3.28.5 (3.28.5-2.el7) Mime-Version: 1.0 X-Spam-Flag: NO X-SW-Source: 2019-q2/txt/msg00009.txt.bz2 Hi, On Tue, 2019-06-25 at 02:05 +0200, Mark Wielaard wrote: > So what about we do a conservative release of 1.0.7 from the current > sourceware.org bzip2.git and simultaneously do a 1.1.0 release from the > gitlab hosted git repo? Referencing each other as the "classic" and > "modern" bzip2 versions. >=20 > Then we can keep the sourceware.org bzip2.git around for ultra > conservative releases based on the current build "system" (that > basically only takes new security issues), using 1.0.8, 1.0.9, etc. But > encourage people towards the 1.1.1, 1.1.2, etc. releases for a more > modern experience, if at all possible. I just pushed the following commit: commit f1e937776c5f331e24cc63a9d8e7ae9445a76761 Author: Mark Wielaard Date: Tue Jun 25 19:22:37 2019 +0200 Add prepare-release.sh script. =20=20=20=20 Script to run to prepare a new release. It will update the release number and tell you to update the CHANGES file and to double check everything looks before doing the release commit and tagging. =20=20=20=20 Afterwards you probably want to run release-update.sh to upload the release and update the website at https://sourceware.org/bzip2/ =20=20=20=20 There are embedded version strings and dates in a couple of places. To keep the script simple remove some that aren't absolutely necessary. =20=20=20=20 README now just points to CHANGES. README.COMPILATION.PROBLEMS only mentions the version once at the top. bzip2.c only mentions the version once when doing --version. manual.xml now doesn't have any embedded versions, just uses &bz-versio= n; everywhere. 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. 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. Cheers, Mark