No active plan on my side, maybe @apurvis? Of course if you want to give it a go that could be an awesome PR :)

Thanks @jarthod. We'll want to start using V5 in June of 2018, so I'll check in. We would be happy to contribute to this, as in June 2018 V4 will start losing support.

i think the playtestcloud people have a fork that is starting to support v5, though i'm not sure where it is: https://github.com/playtestcloud/survey-gizmo-ruby

@cgratigny i had a suggestion for the playtestcloud people over on this commit: playtestcloud@c582719#commitcomment-20474803

i have perused their changes and they look promising though i've never tested them or anything; not sure it's a pure refactor (AKA no functional changes) or if there are real changes hiding amongst the refactor.

it's particularly hard to tell because they changed the whitespace in all the files, which makes it basically impossible to read the diffs.

Hey, Peter here from PlaytestCloud. We might be able to provide a PR for this at some point, but I can't make any guarantees to if or when this will happen.
We are actively using our fork with v5 support and it works well enough. There are some functional changes as well, most notably the possibility to configure/use multiple accounts/API keys in the same app. Which, if I recall correctly, was why we forked in the first place...

seems like maybe @cgratigny could take @peret 's branch and make it into a master PR if @cgratigny is willing to deal with whatever niggling little details remain unresolved

Picking this back up. @peret am I correct in the master branch that you have is using V5 of the API? We are delayed in needing to move to V5.

https://github.com/playtestcloud/survey-gizmo-ruby/tree/master

Yes, that is correct.

I started working on this again and hope to get a proper PR ready during the holidays. I'm wondering though, what the requirements are in terms of backwards compatibility. I guess I can see three ways of approaching this:

1. Replace all fields with what's there in the v5 API, essentially dropping support for v4 fields (although there's some overlap, obviously). This would therefore be a breaking change.
2. Mixing both versions in the same class, essentially just adding fields that are new in v5 and leaving the rest untouched. I get the feeling that this is how it works right now with v3 backwards compatibility?
3. Introducing separate modules for the different API versions and split the fields up.

I think 1 and 3 would be clean solutions, with Option 1 being easier to implement.

I would love to get some opinions on what would be the best approach :)

Thanks for getting back to this @peret, this is much appreciated.

For me the best would be to keep support for v4 and v5 (we can drop v3 if it cleans stuff but otherwise we can keep it) with v5 being the default so it keeps working as before for people already configured for v4. This can be achieved with option 2 or 3, 3 looks cleaner indeed (If it can be made without changing the public API) but probably requires much more changes/time also, no?

Option 1 could be acceptable IMO only if the changes are small and we provide a comprehensive list of things to change otherwise people will simply never upgrade.

Great, thanks for the feedback! I'll see if I can find a way to have multiple versions of the API classes and make them accessible through the same public API.

I finally found the time to prepare a PR to add v5 support 👍