In short, +1 to the above ideas. I think 1.1.0 looks a better choice now. And we'd better have a branch for the bug fixes releases of each feature release, such as branch 1.0.y.
I offline discussed with @bergwolf and @WeiZhang555. To make things simple:
- The major version change, 1.x to 2.x should include significant feature update, or introduce significant changes for the users. The current situation is not such a big change definitely.
- The minor version change, let me talk it later because it is the current debating point.
- The bug fix number, such as 1.0.x to 1.0.y, should only include bug fix or security fix, which should not break main data structures, interfaces, and wire protocol.
As the protobuf definition had been changed, bump version to 1.1.0 is almost what we have to do.
Then we should could define things like the following:
- Any feature update that introduce interface or protobuf definition change
- should not be put into "stable release branch vM.n.y", and should be merged to master.
- should be labeled as "feature update" or similar label, and be listed in the release note later.
- We checkpoint the master to make a new stable release tag 'vM.(n+1).0' and branch 'vM.(n+1).y' at the release date, and make packages.
- Xu