public inbox for bzip2-devel@sourceware.org
 help / color / mirror / Atom feed
From: Mark Wielaard <mark@klomp.org>
To: "Santiago Ruano Rincón" <santiago@debian.org>
Cc: bzip2-devel@sourceware.org,
	Anibal Monsalve Salazar <anibal@debian.org>,
	Anthony Fok <foka@debian.org>,
	Federico Mena Quintero <federico@gnome.org>
Subject: 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: <e27ad880caefea8f5955dcd98ad04e9726205788.camel@klomp.org> (raw)
In-Reply-To: <c55e001242b3e6c33d429c2f5dab2fcd132bcb6b.camel@klomp.org>

Hi,

On Mon, 2019-06-24 at 11:34 +0200, Mark Wielaard wrote:
> So I was thinking, first do a new 1.0.7 release with just the distro
> fixes and the updated project home, and then look at updating the
> rest of the build infrastructure.

I have been pondering what to do about the duplicate efforts to get a
bzip2 1.0.7 release out.

I am really conservative and really think it would be good to do a
release as is from the sourceware.org bzip2.git with just the
security/bug fixes. And I think it would not be good to force the
SO_NAME issue by updating the build system simultaneously. I am also
reluctant to include the "e" and/or O_CLOEXEC fix as is, because a) not
all distros have it currently (or different variants of it) and b) it
might not exist on all platforms, so would need some kind of check for
that first.

On the other hand, I do actually think it would be good to have a more
modern build system, and to force the SO_NAME issue (although I think
we should provide upstream support for changing it back to
libbz2.so.1.0 for those people who have been using it and don't want to
break backward compatibility). And using newer, more modern, possibly
GNU/Linux only features in 2019 would be a good thing.

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.

Cheers,

Mark

  reply	other threads:[~2019-06-25  0:05 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     ` Mark Wielaard [this message]
2019-01-01  0:00       ` Releasing bzip2 1.0.7 and 1.1.0 ? Was: " 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
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=e27ad880caefea8f5955dcd98ad04e9726205788.camel@klomp.org \
    --to=mark@klomp.org \
    --cc=anibal@debian.org \
    --cc=bzip2-devel@sourceware.org \
    --cc=federico@gnome.org \
    --cc=foka@debian.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).