[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Releasing bzip2 1.0.7 and 1.1.0 ? Was: [PATCH] bzip2: Fix return value when combining --test,-t and -q.



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