> 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.