CosmosDb: up the minor build version

[milismsft]

This is done in order to release a hot fix for a CFP related change/bug fix.

[moderakh]

@kushagraThapar what is the versioning process for v3?
I see 3.2.0 is the latest published here (https://mvnrepository.com/artifact/com.microsoft.azure/azure-cosmos)

But in the pom files we have 3.3.0. That's a bit confusing as did we release 3.3.0? if not why 3.3.0 is in the pom? aren't we following the snapshot versioning pattern anymore?

[kushagraThapar]

@kushagraThapar what is the versioning process for v3?
I see 3.2.0 is the latest published here (https://mvnrepository.com/artifact/com.microsoft.azure/azure-cosmos)

But in the pom files we have 3.3.0. That's a bit confusing as did we release 3.3.0? if not why 3.3.0 is in the pom? aren't we following the snapshot versioning pattern anymore?

Yes, it is a bit confusing. We were following the snapshot pattern, but recently someone from azure-sdk team updated our branch with 3.3.0 version.
0dce83b

[moderakh]

@kushagraThapar so this was a one time thing? are we going to switch to snapshot after each release?

[milismsft]

@moderakh This PR will not be merge; its only purpose is to review that I captured all the files that need to be updated with the hot fix patch.

[weshaggard]

@milismsft @moderakh For reference the versioning model we are trying to use is documented in https://github.com/Azure/azure-sdk/blob/master/docs/policies/releases.md. We are not using SNAPSHOT versions in our java repo as they cause too many reliability issues and we generally bump the minor version after a GA release in order to reserve versioning space for any potential hotfixes. That is why the version was bumped from 3.2.0 to 3.3.0, is there a particular reason you guys want to only bump the patch version?

[milismsft]

@weshaggard Just like it is mentioned in the document you referenced, "increments to the patch number (1.1.1 to 1.1.2) indicate hotfixes". This is exactly why we are trying to release 3.2.1 which addresses a bug fix rather than a non-breaking new feature.
Could you list some of reliability issues that "SNAPSHOT" in the version adds?

[weshaggard]

@milismsft thanks for the context I didn't realize you were trying to do a hotfix. We generally keep the master branch with the bumped minor version because we want what is in master to be a different version than what was last published on maven. For hotfixes we generally recommend branching from the last release tag (https://github.com/Azure/azure-sdk/blob/master/docs/policies/repobranching.md#hotfix-branches) and applying just the fix you want, otherwise you risk picking up other changes you didn't want for that hotfix. If you don't believe there are any other changes then then ones you want doing the version change directly in master will accomplish the goal but in general is not the preferred workflow.

The biggest issues with SNAPSHOT versions is that when you depend on them they automatically pull the latest version each time you restore and by doing so makes repeatable builds much more problematic because often times SNAPSHOT builds are daily builds which don't have the same quality bar nor breaking change considerations.