On Wed, Jun 17, 2015 at 12:17 AM, Johannes Schlüter <johan...@schlueters.de> wrote: > On Mon, 2015-06-15 at 22:45 +0700, Pierre Joye wrote: >> 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 I said in early 5.3 times already: I'd love if we'd find a process > and layout to have a single source for all downloads and distribute all > downloads from our mirror network, not having Windows as second class > citizen somewhere else but via all ~70 mirrors. > > Yes this would hurt short term as we'd have to change some processes and > yes it might change URLs (which can be solved via proper redirects) but > long term users get faster downloads and a single place to go with no > confusion like the one that started this thread.
That would me manageable. However as of now it is not possible to do it. systems is hard to deal with as only a few access to one or the other critical boxes, snaps being dead is one of the cases. If we do it, we will also need the ability to do independent releases in case we need to update one of the dependencies (not code change, only provide updates for one or the other DLLs in case of critical security issues). Once the RMs automation tooling things are sorted out, I will be happy to revisit the whole thing and see if we can have a better way to do things. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php