Should we create a branch for the datastore v1beta3 update?

[ajkannan]

The datastore update from v1beta2 to v1beta3 requires touching a lot of code. It would be useful to create a branch off the master branch to provide people with ample opportunity to comment on the changes before it is merged into the master branch. Moreover, a separate branch would allow for smaller PRs, reducing the chance that important changes are buried.

[ajkannan]

cc/ @aozarov

[jgeewax]

@dhermes @stephenplusplus -- thoughts?

On Thu, Sep 10, 2015 at 1:01 PM, Ajay Kannan [email protected]
wrote:

cc/ @aozarov https://github.com/aozarov

—
Reply to this email directly or view it on GitHub
#159 (comment)
.

[dhermes]

I think it's a fine idea, though I'd add that it's probably a good idea to continually rebase the branch on top of master.

It's not entirely clear this is necessary. Do you advise people to install from HEAD? How often do you cut releases?

---

Aside:

1. Is v1beta3 that different?
2. Should gcloud-python start working on v1beta3 changes?
3. When is v1beta3 "live"?

[ajkannan]

We suggest pulling the dependency via release/snapshots pushed to the central repository. Snapshots are updated whenever Travis runs (and the version in the pom.xml file contains the word "snapshot," which is most of the time).

I'll defer on answering the "aside" questions for the time being because I'm not absolutely sure. I know there are a lot of cosmetic changes and a couple behavioral changes (which is why this PR will be large).

[stephenplusplus]

Moreover, a separate branch would allow for smaller PRs, reducing the chance that important changes are buried.

I personally like the idea of a single commit (or group of commits that occurred in series) to represent such a large change. But, wouldn't this be problematic for your releases if you have partial support for the new API version?

Disclaimer: I intentionally try to avoid git discussions, because there are so many workflows and developers tend to keep close to what they're comfortable with. In the end, all roads take you to the same place, so I encourage whatever is most logical for the team and project. If what I said before doesn't apply or you feel those aren't rational concerns, just do your thing and don't waste any time talking about git :)

[aozarov]

Is v1beta3 that different?

It is based on proto3 and was changed to use some of its features such as map and oneof, so there
are many structural changes. No real new features but it fixed known/missing issues such as
cursor per query result item and providing the query in the query result which, I think, is necessary for continuation of GQL queries.

Should gcloud-python start working on v1beta3 changes?

You should check with the datastore team when they plan to stop supporting v1beta2 requests.

When is v1beta3 "live"?

Soon, but AFAIK no public date yet.