make master the development branch

[serious6]

This PR will increment the development Version on master. All Changes related to Version 2.0.x should be placed in the 2.0.x branch. Deploying to master means that this will be included in the next Major release.

[azurecla]

Hi @serious6, I'm your friendly neighborhood Azure Pull Request Bot (You can call me AZPRBOT). Thanks for your contribution!
You've already signed the contribution license agreement. Thanks!
We will now validate the agreement and then real humans will evaluate your PR.

TTYL, AZPRBOT;

[vboctor]

👍

[serious6]

was wondering if master might be 3.0-SNAPSHOT or 2.1-SNAPSHOT ?

[vboctor]

Good question. Given that you called the branch 2.0.x that would make sense. However, I'm thinking that in master we can break APIs, in release branches we can't. Hence, we can have a model where:

• Branch name would be 2.x.x
• For each release we make out of 2.x.x, we call it 2.1.x, 2.2.x, etc. For releases like 2.1.0, 2.1.1, 2.1.2, they would be tags on 2.1.x branch.
• Master would be 3.0-SNAPSHOT
• We can also have a 2.0-SNAPSHOT from the 2.0 main branch.
• We will have specific packages for each release corresponding to a tag in the codebase.

Thoughts?

[serious6]

Looking at spring or apache they resolve their branch-names like 2.0.x, 2.1.x.
So maybe we just need to create another branch that is named 2.1.x and have 3.0 version on master.
We are than able to create new 2.x.x and 3.x.x branches when we are in need.