Hi all,
here are some proposals on how we can manage releases and branches going forward, based on the number of conversations during EclipseCon.
* We should create 1.0.x release branch for potential service releases based on 1.0.0
* After every minor release we should create a corresponding service releases branch in the future (1.1.x, 1.2.x, 2.0.x, ....)
* The master branch is the main development branch
* We should try to do following minor releases in the same way as we did releases in the past
* Every 4 weeks we create a milestone release e.g. 1.1-M1
* After two minor releases we should try to create an actual minor release (1.1.0)
* Service releases are created only when needed, to fix critical bugs, security issues, etc.
* Service release needs to contain minimal number of commits/cherry-picks in order to minimize upgrade issues
* Service releases are always created for the current minor release
* Service release can be created for previous minor releases based on the community demand and discussions
* Breaking API changes should be implemented in a way that doesn't affect backward compatibility, by deprecating (but not removing) old API signatures if possible
* Major releases are done when we can't avoid breaking backward compatibility, after amount of deprecated APIs have been accumulated or community thinks it's time for a major release
* Major release will remove all current API deprecations
* All these are just general guidelines, but every release decision should be discussed in the community. Exception could be made based on the current developments and discussions in the community.
This is just one proposal based on different conversations and best practices already used by many open source projects/communities. Please provide your feedback.
