PhantomJS 1.9.6

[Ariya Hidayat]

Folks,

The latest patch release 1.9.6 is now available. The changes:

2014-01-20: Version 1.9.6

* Updated GhostDriver to version 1.1.1 (issue 11877, 11893)

2014-01-19: Version 1.9.3

* Fixed CoreText performance note on OS X 10.9 (issue 11418)
* Fixed warning of obsolete userSpaceScaleFactor on OS X 10.9
(issue 11612)

If you are a maintainer of a downstream project,
consider/test/encourage the use of this version.

To get the binaries for this release, go to
http://phantomjs.org/download.html. Note that since Google Code
Project Hosting stops offering binary downloads, the files are now
hosted on Bitbucket.

If you're looking for 1.9.3, it was never released (only the git repo
was tagged). Use this version 1.9.6 instead. Curious about 2.x?
Search/check other thread in this mailing-list.

Found problems? Let us know and/or report it:
https://github.com/ariya/phantomjs/issues/11905.

Thanks everyone! Enjoy and spread the love :)

Best regards,



--
Ariya Hidayat, http://ariya.ofilabs.com
http://twitter.com/ariyahidayat
http://google.com/+AriyaHidayat

[Rainer Poisel]

Dear Ariya,

thank you for providing us with this high quality piece of software! 

Would it be possible to keep older binaries online even if a newer release is available? Just in case there is a problem with the new release or in case there are some dependencies i. e. on older interfaces or the like, there would be still a way to go with PhantomJS. 

Thanks once more and best regards,

  Rainer

[Ariya Hidayat]

> Would it be possible to keep older binaries online even if a newer release
> is available? Just in case there is a problem with the new release or in
> case there are some dependencies i. e. on older interfaces or the like,
> there would be still a way to go with PhantomJS.

It's always online, you just need to look at the right place:

https://code.google.com/p/phantomjs/downloads/list?can=1

[Rainer Poisel]

Hej,

thanks and sorry, I couldn't find it right away.

Best regards,
Rainer

> --
> You received this message because you are subscribed to a topic in the Google Groups "phantomjs" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/phantomjs/0GkXtTO6l4Q/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to phantomjs+...@googlegroups.com.
> Visit this group at http://groups.google.com/group/phantomjs.
> For more options, visit https://groups.google.com/groups/opt_out.

[Ivan De Marino]

Ariya,

I think you did the cherry picking wrong.

You haven't picked the "CookieJar module" into 1.9.6, causing the GhostDriver 1.1.1 to be broken.

Question: why the cherry picking?

I mean, it's not like we got a lot of commits to go through: could we just

1) branch (or tag!) the release

2) if a hotfix is needed, proceed on the release branch with the given version

This will make the "usual happy path" clean and in no need for cherry-picking...

But maybe you have a different rationale behind your method.

[Ariya Hidayat]

> I think you did the cherry picking wrong.
> You haven't picked the "CookieJar module" into 1.9.6, causing the
> GhostDriver 1.1.1 to be broken.

Because I didn't pay attention that GhostDriver 1.1 MUST need the new
CookieJar module and does not fallback if it is not available.
Also, nobody else tested the 1.9 branch right before I tagged and released it.

> Question: why the cherry picking?
> I mean, it's not like we got a lot of commits to go through: could we just
> 1) branch (or tag!) the release
> 2) if a hotfix is needed, proceed on the release branch with the given
> version
>
> This will make the "usual happy path" clean and in no need for
> cherry-picking...
>
> But maybe you have a different rationale behind your method.

What other procedure would you suggest? Please walk me through cause I
don't see how it can be done.

Note that I'm just following the consensus here:
https://groups.google.com/d/msg/phantomjs/ouFiiB1UoLw/q9SbThvutxEJ. I
even outlined my plan (tag 1.9.3, don't create binaries for 1.9.3,
cherry-pick GhostDrivers, release 1.9.(3+X) binaries). That's roughly
2 weeks ago and nobody seemed to object that.

[Ivan De Marino]

You are right, I should have followed the conversation more closely. My personal stuff is getting in the way. In the evening I have way less time to follow "what's going on here".

Anyhow, my question can be reduced to: why don't you just release (branch-release?) master?

I had tested extensively the GhostDriver 1.1.1 against master: I had no idea you were going to construct another branch by cherry picking...

NOTE: 1.1.0 didn't use CookieJar - 1.1.1 did, as I have followed closely the development of the PR, and proceeded to add the dependency only after you merged it in.

I suggest we:

- delete 1.9.6 release and tag

- branch current master

- apply/cherry-pick the "release prep commits" only

PS I know that 1.1.1 depending on CookieJar can be criticised as "why haven't you made it backward compatible"... but it's a 1-man project. I can't possible start adding maintenance of old functionalities in there.

It's a miracle I have managed to push it so far...

[Ariya Hidayat]

> Anyhow, my question can be reduced to: why don't you just release
> (branch-release?) master?
>
> I had tested extensively the GhostDriver 1.1.1 against master: I had no idea
> you were going to construct another branch by cherry picking...

Because then it will be an 1.10 release. There are other stuff in
master (unrelated to GhostDriver) which needs to be tested. People
will upgrade from 1.9 and if 1.10 breaks for them and they are not
using GhostDriver, I can foresee bad news.

> I suggest we:
> - delete 1.9.6 release and tag
> - branch current master
> - apply/cherry-pick the "release prep commits" only
>
> PS I know that 1.1.1 depending on CookieJar can be criticised as "why
> haven't you made it backward compatible"... but it's a 1-man project. I
> can't possible start adding maintenance of old functionalities in there.
> It's a miracle I have managed to push it so far...

I think that speaks for all us here. If it's not for the request of
including Ghost Driver 1.1, I would not also bother to make another
release.

In any case, 1.9.7 is needed because 1.9.6 is broken. Now, I'd rather
us not spending too much time on it, every minute fiddling with this
can be spent focusing on 2.0 TP instead (which I really really want to
focus on, but with these distractions...). Our alternatives for 1.9.7:

(1) Remove GhostDriver 1.1.x all together. This will an extremely
quick release, easy to do, and let all of us concentrate on 2.0 TP
instead. Bonus: more testing for future upcoming releases instead of
just dwelling the past.

(2) Include CookieJar in 1.9.7 so that GhostDriver 1.1.1 can work. I'm
hesitant to take this path if I'm the only who'll be testing the
entire releases. If I couldn't get the supposed-to-be-simple 1.9.6
release done correctly, I can imagine other things slip through the
crack.

(3) Tweak GhostDriver 1.1.1 so that it can fallback in case CookieJar
module is not available. I don't know how difficult it is so it's
totally depends on you Ivan to make a judgement.

[Ariya Hidayat]

Another variant to (3) is to use GhostDriver 1.1.0 instead of 1.1.1 so
that it works without CookieJar.

[Ivan De Marino]

On Thursday, 23 January 2014 17:06:40 UTC, Ariya Hidayat wrote:

Another variant to (3) is to use GhostDriver 1.1.0 instead of 1.1.1 so
that it works without CookieJar.

I think this is the way to go: GhostDriver 1.1.0 for 1.9.7.

The people interested in 1.1.1 can still check it out and use that with a personal build.

This would allow to release the other small fixes in 1.9.3 and remove the strict dependency on CookieJar.

 

On Thu, Jan 23, 2014 at 9:02 AM, Ariya Hidayat <ariya....@gmail.com> wrote:
>> Anyhow, my question can be reduced to: why don't you just release
>> (branch-release?) master?
>>
>> I had tested extensively the GhostDriver 1.1.1 against master: I had no idea
>> you were going to construct another branch by cherry picking...
>
> Because then it will be an 1.10 release. There are other stuff in
> master (unrelated to GhostDriver) which needs to be tested. People
> will upgrade from 1.9 and if 1.10 breaks for them and they are not
> using GhostDriver, I can foresee bad news.

Question: how untested stuff got into "master"?

We got tests in place to validate any regression. And, as far as I read, you (others and me sometimes) do make sure that a PR doesn't break anything.

And, if it adds a feature, that comes with tests.

How do we arrive to "we have untested stuff"?

Maybe I have missed something...

[Ariya Hidayat]

> I think this is the way to go: GhostDriver 1.1.0 for 1.9.7.
>
> The people interested in 1.1.1 can still check it out and use that with a
> personal build.
> This would allow to release the other small fixes in 1.9.3 and remove the
> strict dependency on CookieJar.

Sounds like a good compromise. Thank you Ivan!

> Question: how untested stuff got into "master"?
> We got tests in place to validate any regression. And, as far as I read, you
> (others and me sometimes) do make sure that a PR doesn't break anything.
> And, if it adds a feature, that comes with tests.
>
> How do we arrive to "we have untested stuff"?
> Maybe I have missed something...

It's a generic observation. The fact that there's no regression is
just one factor. I haven't used master branch in my own daily usage so
I don't know if it ever breaks something. If someone is doing that and
they can vouch the stability of master branch, then it's a different
story.

In all cases, doing faster and more confident releases like that
requires the infrastructure help. Without that, it's too risky and we
don't want to spend effort rolling out subsequent patch releases to
hotfix any unforeseen issues.

[Ivan De Marino]

> Question: how untested stuff got into "master"?
> We got tests in place to validate any regression. And, as far as I read, you
> (others and me sometimes) do make sure that a PR doesn't break anything.
> And, if it adds a feature, that comes with tests.
>
> How do we arrive to "we have untested stuff"?
> Maybe I have missed something...

It's a generic observation. The fact that there's no regression is
just one factor. I haven't used master branch in my own daily usage so
I don't know if it ever breaks something. If someone is doing that and
they can vouch the stability of master branch, then it's a different
story.

In all cases, doing faster and more confident releases like that
requires the infrastructure help. Without that, it's too risky and we
don't want to spend effort rolling out subsequent patch releases to
hotfix any unforeseen issues.

Personally, I do check `master` every time I do work on PhantomJS or GhostDriver.

But, in truth, I do it only on mac at the moment.

I have in the back of my mind to run a simple task to make the Jasmine Tests + GhostDriver tests (that for now are only on the GhostDriver repo) break the TravisCI build.

Yes, we would be testing only on Travis's Linux, but still...

What do you think?

[Ariya Hidayat]

> I have in the back of my mind to run a simple task to make the Jasmine Tests
> + GhostDriver tests (that for now are only on the GhostDriver repo) break
> the TravisCI build.
> Yes, we would be testing only on Travis's Linux, but still...

This was the idea (at least months back, I can't bother to search the archive).

After a fresh build of PhantomJS (on Travis CI), run some scripts e.g.:

test-casperjs.sh
test-ghostdriver.sh
test-poltergeist.sh

or any other important "downstream" projects. Each script will grab
the package from the recent stable release of the project (e.g. wget
from its GitHub tagged tarball), unpack it, setup the necessary
environment, run the test and report back the result.