| Re: [eclipse.org-architecture-council] The Art of Project ReleaseNaming |
I see some conflicting requirements here. On one hand we call for aligning major/minor version numbers with API compatibility and maturity (e.g., no breaking API change within a major version; provisional API should stabilize within x number of version etc.). On the other hand some would like conformity of version numbers of different components in a release train. However projects don’t progress at the same pace. I understand a release train to be a set of components that promise to work with each other and preferably take advantage of each other’s new features. We are not asking each project to put in similar amount of change to their APIs or feature set in a new train.
I suggest that we leave versioning a decision of each project. Perhaps Eclipse foundation should market each release using only the train name and refrain from using the version number of any train participants (i.e., Galileo != 3.5). Each participating project may decide to use the train name alone, or a train name + version number (e.g., BIRT Galileo or BIRT 2.5 (Galileo)). What we do need is a quick reference page for users to find out what versions of what projects constitute an Eclipse train release, i.e. , Eclipse Galileo = Platform 3.5 + Mylyn 3.2 + BIRT 2.5 + …