This is really unacceptable as it doesn't follow any established open source practices to say the least.
On top of that there is no debate, discussion etc. Community comments like #187 are simply ignored with clear show of ignorance and disrespect . . .I'm gonna merge this pr since it's just a version bump. . .

cc @duglin

Also, what s milestone1-attempt2? Should it be at the very least milestone2 since the firs one apparently was a bust?

Let's discuss this on the SDK call today

In the meantime, it's my understanding that this "milestone" is more like something between what's available at HEAD and a "release candidate" - not officially saying "we're close to shipping" but more "official" than grabbing the latest code. So, I wonder if people are reacting to the word "milestone" and thinking it's more official (or bigger) than it really intended to be.

Perhaps we should look to document the process and terms to get everyone on the same page. Is this something that should be global to all SDKs or should each one decide their own?

@n3wscott @lance @clemensv @markpeek @slinkydeveloper

Regarding the name 2.0.0-milestone1. This is a perfectly valid semver name for a prerelease version, per the semver spec (although I would have made it milestone.1). I also see this as something between snapshot and a full release. Without knowing exactly why @slinkydeveloper chose the milestone moniker, I interpret this as one of a series of releases that will lead up to 2.0.0, each of which adds a new bit of functionality planned for the final release.

It may have been good to have a discussion around exactly what naming conventions this repository intends to use, but on the surface nothing here seems "really unacceptable" to me. As I see it, this is a semver name for a prerelease version - but not a release candidate (RC) or SNAPSHOT. Naming conventions for prerelease artifacts may be unique to each language or to each company, but standardizing on semver would probably be good overall. That's what this version is, so I am not sure I understand what the real issue here is.

Also, related... I think having some common processes defined around releases is good. For example, what notifications are provided, and to whom and when? Or is there a common expectation for SDK releases to go through any validation beyond the tests that exist in each repository? Is there a common expectation that SDKs provide candidate releases and/or alpha/beta releases. How/when does an SDK decide to cut a new release? Having these expectations written in some form of governance document would be very helpful in avoiding misunderstandings.

As a data point, with the JavaScript SDK 2.0.0 release, I started by opening an issue outlining what was going to be in the release and providing an opportunity for the community to comment, raise concerns etc.