From: Federico Mena Quintero <federico@gnome.org>
To: "Mark Wielaard" <mark@klomp.org>,
"Santiago Ruano Rincón" <santiago@debian.org>
Cc: bzip2-devel@sourceware.org,
Anibal Monsalve Salazar <anibal@debian.org>,
Anthony Fok <foka@debian.org>
Subject: Re: Releasing bzip2 1.0.7 and 1.1.0 ? Was: [PATCH] bzip2: Fix return value when combining --test,-t and -q.
Date: Tue, 01 Jan 2019 00:00:00 -0000 [thread overview]
Message-ID: <28b061f6f1e5ea10de587c99b02817036b6f934e.camel@gnome.org> (raw)
In-Reply-To: <abdce48189473c5efe987804bb38d8eb6048fa24.camel@klomp.org>
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
next prev parent reply other threads:[~2019-06-26 2:22 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-01 0:00 Mark Wielaard
2019-01-01 0:00 ` Santiago Ruano Rincón
2019-01-01 0:00 ` Mark Wielaard
2019-01-01 0:00 ` Releasing bzip2 1.0.7 and 1.1.0 ? Was: " Mark Wielaard
2019-01-01 0:00 ` Mark Wielaard
2019-01-01 0:00 ` Federico Mena Quintero
2019-01-01 0:00 ` Mark Wielaard
2019-01-01 0:00 ` Federico Mena Quintero [this message]
2019-01-01 0:00 ` Mark Wielaard
2019-01-01 0:00 ` Mark Wielaard
2019-01-01 0:00 ` Federico Mena Quintero
2019-01-01 0:00 ` Mark Wielaard
2019-01-01 0:00 ` Some cherry-picks (Was: [PATCH] bzip2: Fix return value when combining --test,-t and -q.) Mark Wielaard
2019-01-01 0:00 ` Federico Mena Quintero
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=28b061f6f1e5ea10de587c99b02817036b6f934e.camel@gnome.org \
--to=federico@gnome.org \
--cc=anibal@debian.org \
--cc=bzip2-devel@sourceware.org \
--cc=foka@debian.org \
--cc=mark@klomp.org \
--cc=santiago@debian.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).