Migrate from com.google.gcloud.* to com.google.cloud

[aozarov]

The current plan is to:

1. rename our Java package structure from com.google.gcloud. to com.google.cloud.

2. rename maven group-id from com.google.gcloud to com.google.cloud.

For now we are going to keep the following:

1. repository (and repository name).

2. maven artifact-id (should match repository name and therefore should be kept for now as gcloud-java).

3. directory structure and maven modules.

/cc @jgeewax

[aozarov]

Was applied on master and released.
We need to make sure that we also apply it on the compute-alpha, gcs-nio and dns-alpha-batch branches.

/cc @mziccard @mderka @jart @jean-philippe-martin

[jean-philippe-martin]

Done as part of PR #937 (commit shown above).

[jart]

I'm sorry I was on vacation the past few weeks. I like the new package name. But I'm very surprised that such a radical change is happening. I've also noticed a lot of other naming changes prior to this.

I've found it challenging as a 20% contributor to keep up with the pace of changes. I imagine it would be even more difficult for an independent user who isn't in collaboration with the developers.

The reason I'm concerned is because I'm going to be promoting this project in the near future. I take an extremely conservative outlook on software. For that reason, I think some people trust my judgement. So when I run around telling everyone that gcs-nio / gcloud-java is the greatest thing they need to start using immediately, I want to make sure I'm offering the best recommendation possible.

So what assurances can gcloud-java offer that its API will become stable? What processes are being used, and will continue to be used, for API review?

[mziccard]

Hi @jart,
I believe your concerns are more than reasonable however I see this from a different perspective. gcloud-java is in version 0.2.0 and we document in the README it is a work in progress:

Note: This client is a work-in-progress, and may occasionally make backwards-incompatible changes.

Until we kick out our first major release (i.e. 1.0.0) it's reasonable to assume that the API will make non-backward compatible changes. This very same approach has bean adopted in other gcloud-* libraries. Instead of seeing this as a released API that keeps changing this should be seen as a work-in-progress API that allows users to shape it and use/familiarize with it while being developed.

Set aside the philosophical discussion we plan to release version 1.0.0 (can't give you a sure ETA yet) that will make at least datastore and storage APIs stable. Once our first major version is released we will guarantee that no backward compatible changes unless a new major is released.

BTW, one more API change is planned for storage that is changing the way batches can be handled. This will be a major improvement in usability and that way batch handling wille be standardized across modules (also used in dns). No other backwards-incompatible changes are planned at the moment.

Hope this answers your concerns. /cc-ing @jgeewax in case he wants to add something

[jart]

I figured as much. That sounds perfectly reasonable. It would be nice to have an ETA for 1.0.

[mziccard]

This was fixed in compute in #970