"I think one major problem is that
not all release train projects know that they can ship new features and
APIs with an update release. If we change that perception, we can already
improve things quite a bit for our users and deliver things faster to them."
What you said can already be done with
the update releases. We just did a bad job communicating this.
Eclipse Planning Council
private list <eclipse.org-planning-council@xxxxxxxxxxx> Date:
05.10.2017 17:35 Subject:
Simultaneous ReleaseBrainstorming Sent by:
On Thu, Oct 5, 2017 at 6:14 PM, Mikaël Barbero <mikael.barbero@xxxxxxxxxxxxxxxxxxxxxx> wrote: > No worries, it was way too abstruse. > > You said that we could convert update releases to normal releases,
but we > should probably allow breakage in only one or two. Then, what is the > difference between an update release and a normal release where breakage
is > not allowed?
Update releases currently contain only backported fixes(and rarely new features/apis) for most of the lower level projects in the release train. So projects higher in the stack were not able to use/rely on these new features for a year while doing their update releases. By having normal releases for the whole release train we will get whatever is developed in the lower level projects available in every release much like it is now for some of the projects like Mylyn/EGit. Now, nothing from the new development in SWT/Equinox/Platform... Photon development is available to rest of the projects in the release train as they do Oxygen.x contributions so practically most projects move to newer dependencies only after they release their .2 release. With the new plan this would happen every 3 months as every project will contribute their new version often (if they have one) and not keeping new content away from users for months (Jul-Mar) like it happens now.