search

phar-io / phive

The Phar Installation and Verification Environment (PHIVE)
https://phar.io
BSD 3-Clause "New" or "Revised" License
582 stars 45 forks source link

What about rolling releases? #26

Closed sagikazarmark closed 6 years ago

sagikazarmark commented 8 years ago

Like composer? It is unlikely that you can pin point a specific release with a signature? Will those ever be supported?

theseer commented 8 years ago

If it's a release, it has to have a signature. The only thing we can potentially argue about is how the "version" is to be specified. For now phive assumes a semantic version identifier. I do realize this may not apply for all phars we would want to install.

Independet from that, every release should be verifiable. If the developers of composer (or any other tool for that matter) do not provide any means to verify their releases, maybe that should be considered a bug in their release process. As long as they ask their users to directly pipe a downloaded script into execution, that's the least of their problems though ;)

sagikazarmark commented 8 years ago

I agree that a version should be identifiable. For example composer uses the actual commit hash of the build I think.

I am not sure however how a release cycle like this could integrate with phive. Since it has a more frequent release cycle, some automatization would be necessary otherwise it would be a hassle to register the release in the repository every time.

theseer commented 8 years ago

Yes, composer uses the commit hash (which imho is about the worst choice for an identifier one could possibly pick).

But you're perfectly right, manual registration is definitely not an option and we already have phar-site-generator to generate the repository information file (used for instance at phar.phpunit.de) and there's issue #22. There are of course more options, all we need is a pointer to get data from.

sagikazarmark commented 8 years ago

:+1:

theseer commented 6 years ago

We do need something that identifies a release. For now, that something is a semantic version number.

I don't see anything for us to implement here. At least until there is an actual use case we could look into.