[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 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.
> 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 <mark@klomp.org>
Date:   Tue Jun 25 19:22:37 2019 +0200

    Add prepare-release.sh script.
    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.
    Afterwards you probably want to run release-update.sh to upload
    the release and update the website at https://sourceware.org/bzip2/
    There are embedded version strings and dates in a couple of places.
    To keep the script simple remove some that aren't absolutely necessary.
    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-version;

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.