Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] Change in Eclipse SDK release cadence


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 you.

Thanks,


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.




Back to the top