[release management] Drop .gz and .zip release packaging?
Boost releases are currently packaged four ways. With CR/NL line endings: boost_1_37_0_beta1.7z 27,340,204 boost_1_37_0_beta1.zip 57,017,457 With NL line endings: boost_1_37_0_beta1.tar.bz2 29,494,538 boost_1_37_0_beta1.tar.gz 36,436,716 I'd like to drop the .zip and .gz packages, starting with release 1.38.0. The primary motivation is a personal one; as release manager I do a lot of FTP transfers and would like to spend less time waiting for the big .zip and .gz packages to upload/download. The problem I see is that CR/NL users still download .zip files twice as often as .7z, and NL users still download about as many .gz packages as bz2. Comments? --Beman
Beman Dawes wrote:
Boost releases are currently packaged four ways.
The problem I see is that CR/NL users still download .zip files twice as often as .7z, and NL users still download about as many .gz packages as bz2.
That seems to be a good argument against the change, while most Linux distro's have bz2, 7z has rather less machine penetration I suspect. I also believe that many commercial *nix distro's don't have bz2 support as standard? John.
On Thu, Oct 23, 2008 at 8:28 AM, John Maddock <john@johnmaddock.co.uk> wrote:
Beman Dawes wrote:
Boost releases are currently packaged four ways.
The problem I see is that CR/NL users still download .zip files twice as often as .7z, and NL users still download about as many .gz packages as bz2.
That seems to be a good argument against the change, while most Linux distro's have bz2, 7z has rather less machine penetration I suspect. I also believe that many commercial *nix distro's don't have bz2 support as standard?
But are not users of Boost supposed to be able to cope with different compression tools? A link to 7-zip and a description of how to unpack bz2 ought to be enough. /$
Quoting Henrik Sundberg <storangen@gmail.com>:
On Thu, Oct 23, 2008 at 8:28 AM, John Maddock <john@johnmaddock.co.uk> wrote:
Beman Dawes wrote:
Boost releases are currently packaged four ways.
The problem I see is that CR/NL users still download .zip files twice as often as .7z, and NL users still download about as many .gz packages as bz2.
That seems to be a good argument against the change, while most Linux distro's have bz2, 7z has rather less machine penetration I suspect. I also believe that many commercial *nix distro's don't have bz2 support as standard?
But are not users of Boost supposed to be able to cope with different compression tools? A link to 7-zip and a description of how to unpack bz2 ought to be enough.
Not in some (many?) corporate environments, it wouldn't. Here we can download .zip files because the software sitting on the firewall opens the .zip and check that none of the contained files contain viruses. It doesn't do the same to .7z files, so it doesn't permit them through. Just one data point... Pete
On Oct 23, 2008, at 8:28 AM, John Maddock wrote:
Beman Dawes wrote:
Boost releases are currently packaged four ways.
The problem I see is that CR/NL users still download .zip files twice as often as .7z, and NL users still download about as many .gz packages as bz2.
That seems to be a good argument against the change, while most Linux distro's have bz2, 7z has rather less machine penetration I suspect. I also believe that many commercial *nix distro's don't have bz2 support as standard?
I would like to second John here if I am allowed (being more or less new to the list). I usually go with the .gz version on Windows as well....although it would not matter as far as I know since there is no built-in support for neither .gz nor bz2 anyway (I am using a different explorer which has built-in capabilities for .zip/.gz) However, I certainly understand the extra burden this puts on the release manager. Ciao, Andreas
On Thu, Oct 23, 2008 at 8:28 AM, John Maddock <john@johnmaddock.co.uk>wrote:
Beman Dawes wrote:
Boost releases are currently packaged four ways.
The problem I see is that CR/NL users still download .zip files
twice as often as .7z, and NL users still download about as many .gz packages as bz2.
That seems to be a good argument against the change, while most Linux distro's have bz2, 7z has rather less machine penetration I suspect. I also believe that many commercial *nix distro's don't have bz2 support as standard?
That's true, but both 7z and bz2 are trivial to obtain and install nowadays. We could document how to do that. I know we are probably a bit ahead of the uptake curve for both of these, but they are well on their way to becoming the standard on Windows and POSIX-like systems respectively. --Beman
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Beman Dawes Sent: 23 October 2008 13:18 To: Boost Developers list Subject: [boost] [release management] Drop .gz and .zip release packaging?
Boost releases are currently packaged four ways.
With CR/NL line endings:
boost_1_37_0_beta1.7z 27,340,204 boost_1_37_0_beta1.zip 57,017,457
With NL line endings:
boost_1_37_0_beta1.tar.bz2 29,494,538 boost_1_37_0_beta1.tar.gz 36,436,716
I'd like to drop the .zip and .gz packages, starting with release 1.38.0. The primary motivation is a personal one; as release manager I do a lot of FTP transfers and would like to spend less time waiting for the big .zip and .gz packages to upload/download.
I can quite understand your wish for this, but I am sure that there are many potential Boost users who will find this troublesome, or impossible. Can I suggest a compromise: * All the beta releases will only be in your preferred .7z and bz2, (on the grounds that potential beta testers will be able to handle these formats easily). * final release will be issued 1st in these formats, * later when the dust has settled on a release, .zip and .gz versions will be issued. Paul --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow@hetp.u-net.com
Beman Dawes wrote:
Boost releases are currently packaged four ways.
With CR/NL line endings:
boost_1_37_0_beta1.7z 27,340,204 boost_1_37_0_beta1.zip 57,017,457
With NL line endings:
boost_1_37_0_beta1.tar.bz2 29,494,538 boost_1_37_0_beta1.tar.gz 36,436,716
I'd like to drop the .zip and .gz packages, starting with release 1.38.0. The primary motivation is a personal one; as release manager I do a lot of FTP transfers and would like to spend less time waiting for the big .zip and .gz packages to upload/download.
The problem I see is that CR/NL users still download .zip files twice as often as .7z, and NL users still download about as many .gz packages as bz2.
I think this is a premature optimization. Sure it saves you some time, but how much extra time does it cost a user who has to find bz2 or 7z decompression binaries, install them and figure out how to use them? When multiplied by the number of users who might be in that situation, there's more time saved overall if you spend a bit more of yours. -- Jon Biggar jon@biggar.org jon@floorboard.com
Beman Dawes wrote:
I'd like to drop the .zip and .gz packages, starting with release 1.38.0. The primary motivation is a personal one; as release manager I do a lot of FTP transfers and would like to spend less time waiting for the big .zip and .gz packages to upload/download.
The problem I see is that CR/NL users still download .zip files twice as often as .7z, and NL users still download about as many .gz packages as bz2.
Comments?
Just a thought: Is there any hope of a system where conversion to target archive types are done at the download site after upload? Conceptually, the download site could be configured to convert to derived archive forms after upload, or lazily into a disk cache on download requests. Even the the CR/NL <--> NL translations could be done this way if list of mime types where provided, or is it needed to convert in string literals in binary files as well? If disk space usage and backup is a problem for the download sites, they may be motivated for a cache based solution like this as it may save disk space for old releases and betas while maintaining or improving the service. A system with a contents list file with entries of filename, mime-type and MD5 checksums could together with relatively simple scripts be used to verify quality of the service. -- Bjørn
Beman Dawes wrote:
I'd like to drop the .zip and .gz packages, starting with release 1.38.0.
Please, no. If you want to drop some some packages, I'd drop the .7z and .bz2. On Windows, .zip is standard ... on Vista, Explorer has built-in support for it. And on *nix, .gz is the de-facto standard. IMO, .7z and .bz2 are nice-to-have but not necessary, and certainly shouldn't be the only ones we provide. -- Eric Niebler BoostPro Computing http://www.boostpro.com
on Thu Oct 23 2008, Eric Niebler <eric-AT-boost-consulting.com> wrote:
Beman Dawes wrote:
I'd like to drop the .zip and .gz packages, starting with release 1.38.0.
Please, no. If you want to drop some some packages, I'd drop the .7z and .bz2. On Windows, .zip is standard ... on Vista, Explorer has built-in support for it. And on *nix, .gz is the de-facto standard. IMO, .7z and .bz2 are nice-to-have but not necessary, and certainly shouldn't be the only ones we provide.
I have to agree with Eric. Standards and familiarity are much more important than minimizing transfer size where barriers-to-entry are concerned, IMO. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
Beman Dawes wrote:
Boost releases are currently packaged four ways.
With CR/NL line endings:
boost_1_37_0_beta1.7z 27,340,204 boost_1_37_0_beta1.zip 57,017,457
With NL line endings:
boost_1_37_0_beta1.tar.bz2 29,494,538 boost_1_37_0_beta1.tar.gz 36,436,716
I'd like to drop the .zip and .gz packages, starting with release 1.38.0. The primary motivation is a personal one; as release manager I do a lot of FTP transfers and would like to spend less time waiting for the big .zip and .gz packages to upload/download.
The problem I see is that CR/NL users still download .zip files twice as often as .7z, and NL users still download about as many .gz packages as bz2.
Comments?
I vote to keep zip available, if I may. I know that 7z is available freely but I feel quite relucant about installing any additional software, unless absolutely needed. Traditional zip has a far better support in other software, like file managers, for example, than 7z. As for gz/bz2 choice, I'm good with either, since they have relatively the same degree of support on the platforms I work with (Windows and Linux).
participants (11)
-
Andreas Masur -
Andrey Semashev -
Beman Dawes -
Bjørn Roald -
David Abrahams -
Eric Niebler -
Henrik Sundberg -
John Maddock -
Jon Biggar -
Paul A Bristow -
Peter Bartlett