search

phpv8 / v8js

V8 Javascript Engine for PHP — This PHP extension embeds the Google V8 Javascript Engine
http://pecl.php.net/package/v8js
MIT License
1.83k stars 200 forks source link

Upcoming changes to pinepain/libv8 layout #356

Closed pinepain closed 6 years ago

pinepain commented 6 years ago

Hello v8js folks!

I'm the pinepain/libv8-* PPAs family maintainer and I have few pending changes to announce:

  1. All PPAs mentioned in https://github.com/phpv8/v8js/issues/345 are subject of immediate removal. Please, use pinepain/libv8-archived to get old versions.
  2. All newever versions (libv8-6.4, libv8-6.5 and libv8-6.6) are subject to be moved into pinepain/libv8 PPA. Also, libv8-6.4, libv8-6.5 and libv8-6.6 are subjects of immediate removal too.
  3. All further newer libv8 versions would go to pinepain/libv8 PPA, everything older than two versions will be moving to pinepain/libv8-archived without any further notices.

What it means to those who depend on these PPAs:

in short, just add both PPAs:

sudo add-apt-repository ppa:pinepain/libv8
sudo add-apt-repository ppa:pinepain/libv8-archived
sudo apt-get update

and keep installing libv8-X.Y packages(s) in a same way you did before.

@stesie here's the fix for v8js - https://github.com/phpv8/v8js/pull/355

I know that many users depend on these PPA and I'm terribly sorry for any inconvenience it will make to you, however I this would be a good change which prevent any further BC-breaks and will reduce work for me to maintain it.

For those who have to maintain and support own versions and layout, feels free to use PPA packaging scripts I use.

virgofx commented 6 years ago

@pinepain What's the purpose of the libv8 and libv8-archived PPAs when the explicit version is required for installation: e.g. libv8-6.6?

What's happened now is end-users can no longer rest assurred that build scripts/provisioners will work as time passes as the installation gets migrated from current to archived. (This has already happened to me a few times) The reference to the PPA needs to be transitioned from current to archived (This is a huge pain)

It would be better to just keep ONE PPA such that these scripts will continue to work over time with each new major release getting installed with the appropriate major prefix as you have.

This way, you let the end user determine what is "old" or "archived".

pinepain commented 6 years ago

@virgofx Thanks for the feedback. I see your point. The difference between libv8 and libv8-archived is that libv8-archived container libv8 versions that are not supported and won't receive any fixes and patches neither from me nor from Google (especially from Google). For now, libv8-archived is just a limbo for those who can't upgrade to newer v8 version (I feel your pain) and it will show a warning when adding that repo.

As to scripts/provisioners, if you want to make sure you are fully covered, you can add both PPA as cited in original message above and as it done in https://github.com/phpv8/v8js/pull/355/files. It's not the best solution, however it will take away the pain maintaining where the version you need reside.

The changes I introduce is an attempt to serve community as honestly, I plan to moved my infrastructure from PPA to containers (public images available under pinepain/libv8 name) after recent Launchpad sort-of-outage when they wasn't running build for few days and I was in urgency to roll update.

UPD: reflected that I plan to move from PPA to containers, however it's not yet done.

virgofx commented 6 years ago

Totally -- It made sense initially, until I realized my version got bumped down. I'm totally fine with the work-around, will add both as that will solve the issue.

And I get it -- older V8s aren't being updated -- makes sense ... I just thought it would be easier from your perspective to only maintain one PPA -- with just the current list of supported releases in the top level readme/website ... less migrating and moving.

Worth a thought if it makes sense ... it might be easier.

pinepain commented 6 years ago

It is true that one would be simpler, however libv8-archived was introduced just recently and I don't think breaking it would make those who read notice https://github.com/phpv8/v8js/issues/345 happy. Also, showing a warning and notice regards upgrading may convince someone to upgrade (though, less likely).

virgofx commented 6 years ago

I personally don't know how many people have added the libv8-archived; however, I think it would be okay to just move everything into libv8 and then deprecate. People will figure it out ;P