On Jun 15, 2015 10:38 PM, "Anatol Belski" <anatol....@belski.net> wrote: > > Hi Johannes, > > > -----Original Message----- > > From: Johannes Schlüter [mailto:johan...@schlueters.de] > > Sent: Monday, June 15, 2015 4:52 PM > > To: Christoph Becker > > Cc: Hannes Magnusson; Anatol Belski; PHP Development; PHP Webmaster ML > > Subject: Re: [PHP-DEV] PHP7 releases vs Windows Sources? > > > > On Mon, 2015-06-15 at 16:20 +0200, Christoph Becker wrote: > > > Hannes Magnusson wrote: > > > > > > > Then this fix doesn't make any sense -- you are saying if I download > > > > the .tar.gz and .zip and extract those two, I will have precisely > > > > the same sources? > > > > Then this fix should be reverted as there is isn't any special > > > > Windows Sources and the official releases should work just fine. > > > > > > There is some difference (timestamps?) which causes building from the > > > tarred sources to fail on Windows (see bug #69829). > > > > "touching" generated files as part of the packaging process is a good idea for all > > platforms. > > > > > Furthermore > > > extracting the tarred sources with 7zip (which seems to be a pretty > > > common archiver) results in spurious PaxHeaders.##### directories, > > > what is bug in 7zip[1], and doesn't really affect the build, but is > > > confusing nonetheless (and requires more disk space). > > > > > > At least until these issue are solved, IMO it's better to link to the > > > "Windows" sources packaged as .zip. > > > > If there is a need for zip archives I'd put them next to tar.gz etc. and distribute > > them via our mirror network. > > > Yep, this could work and were probably proper solution. Except we wouldn't add some issue for the non Windows users :) I'm not sure, why is it done so ATM, probably it has its historical reasons. But this would probably cause us need to update the release process procedure? And, for PHP7 or for any other as well? Currently that zipball is just generated with the build process, so it'll need to be sent over somehow. Were anyway doable, wondering what the other RMs would say. Frankly, I'd leave it as it is - as long as it's reachable and documented.
The reason is that we generate zip for binaries, and we just do the same for the src, providing zip archives using the same naming convention. We know many other tools relying on these zip, normalized URLs, so we must keep them. It does not hurt anyone anyway. As of fork, custom patches etc, there is no such thing. Cheers, Pierre
