If you have any concerns or doubts,
please open a bug report and post it here.
David Williams <david_williams@xxxxxxx> To:
03.12.2017 01:50 Subject:
Change in Eclipse SDK release cadence Sent by:
What's missing from this announcement is what this means regarding versions
or versioning. I can guess, but it would be better for you to be explicit.
I am assuming you mean something more than "maintenance release"
(i.e., a change in the third field, or 'micro,' of version). Since to mean that, it would be a simple change in terminology (for the
sake of marketing, I assume, but doubt that is the case).
I am also assuming you do not mean a major, API breaking change (change
in the first field, or 'major,' of version). Since to mean that, would be to break many adapters' product and maintenance
strategies -- and if so, all the more reason to be very explicit! :)
So, that leaves an "update release" -- a change in the second
field (or, 'minor' in OSGi terms) -- typically done when the code has a new API or a new feature that does not break existing code. If that is the case, it seems that everyone else has been doing update
releases for a long time and the Platform has had the ability to do so, but never has in practice.
I would guess you mean this latter case (an "update release")
but suggest you make it explicit or explain whatever else it may mean to
On 12/01/2017 06:47 AM, Aleksandar Kurtakov wrote: After the Eclipse Photon release, a change in the
Eclipse SDK release cadence is coming: Releases will happen every 3 months from master.
This will reduce the huge waiting time that happens now for people contributing early in the development cycle, who had to wait for up to almost a year to see their feature or fix become available. Given the ever increasing pace of software development this is needed to keep the Eclipse SDK competitive, and to eliminate the burden on maintainers of doing backporting.
Maintenance releases will no longer happen and people requiring a fix will simply update to the next release.
Regarding the release train, each of the quarterly releases will be contributed to the respective release train version.
The API removal policy remains the same, including giving 2 years notice before removing deprecated API. API removals can be announced in all four releases, and as a consequence API removals can also happen in all releases.