Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[cross-project-issues-dev] Changing name of Simultaneous "Service Release" to "update release"

The Planning Council has decided to name the September and February releases Mars.1 and Mars.2, instead of SR1 and SR2. And, in general, the term "update release" should be used instead of "service release" for these Simultaneous Releases. I have updated the Mars Plan document to reflect these changes. See

The reason for this change is pretty simple, and long over due. There has been no real change in policies or requirements about "what can go into" these releases, but there is a lot of confusion and mis-perception about what can go into them.  We often hear the misstatement that "nothing new can be added, except once per year".  That was the goal, many years ago, but has not been true for years, (and before that, was not enforced) but apparently many people still think that "SR" is for "service only" and only for projects that were in the June release.  The new naming is to improve that perception and we hope reduce any misunderstanding.  It does remain true that no one can add breaking changes and no one should remove features in update releases (without going through the Exception Process). And, if not obvious, must still meet all the usual Simultaneous Release requirements.

We in the Planning Council tried to pick a "generic" names, Mars.1 and Mars.2, since some projects may in fact do "service only" while some projects may have a "minor release" and some new projects may join the train. That is, we did not want to over-correct the naming and imply that "everything was a new, complete release and was a replacement for the June release". We do still expect that other project's or adopter's code built "on top of" the initial June release, will still work fine on update releases (with some few exceptions, probably).  

If committers have been "holding back", due to this mis-perception or mis-communication, the Planning Council would like to encourage you to go "full speed ahead"! Additions and innovations are always good -- just don't break others!  I know that some committers do have this mis-understanding about the update (aka service) releases, so I ask all project leads to "spread the word".  Also, probably it is obvious, each project is different. Some projects, either based on their leadership, resources, or their place in the architecture, may intentionally want to have "service only" ... and, that is fine too -- and, that also needs to be communicated well to your project's committers.

Strictly speaking, this terminology only applies to the simultaneous, coordinated release train. It does not change any EDP rules or process requirements of projects having release reviews for minor releases, nor any other Eclipse Foundation requirements.

If any questions, please ask. Plus, if this causes issues or problems we have not anticipated, please let us know.


Back to the top