Re: [eclipse.org-planning-council] Simultaneous ReleaseBrainstorming

["Daniel Megert" <daniel_megert@xxxxxxxxxx>]

As mentioned before;

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

Dani



From:      
 Aleksandar Kurtakov
<akurtako@xxxxxxxxxx>
To:      
 Eclipse Planning Council
private list <eclipse.org-planning-council@xxxxxxxxxxx>
Date:      
 05.10.2017 17:35
Subject:    
   Re: [eclipse.org-planning-council]
Simultaneous ReleaseBrainstorming
Sent by:    
   eclipse.org-planning-council-bounces@xxxxxxxxxxx

---

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.

>
> Mikael
>
> Le 5 oct. 2017 à 17:09, Daniel Megert <daniel_megert@xxxxxxxxxx>
a écrit :
>
>> How an update release converted to a "normal" release
without the
>> permission to break API is different from an update release?
>
> Sorry, I have troubles to parse this.
>
> Dani
>
>
>
> From:        Mikaël Barbero <mikael.barbero@xxxxxxxxxxxxxxxxxxxxxx>
> To:        Eclipse Planning Council private list
> <eclipse.org-planning-council@xxxxxxxxxxx>
> Date:        05.10.2017 17:03
> Subject:        Re: [eclipse.org-planning-council]
Simultaneous
> ReleaseBrainstorming
> Sent by:        eclipse.org-planning-council-bounces@xxxxxxxxxxx
> ________________________________
>
>
>
> I see two main changes when converting the update releases to "normal"
> releases:
> - It would probably allow (API) breakage like we allow with the yearly
> release. Not sure whether this is really something good for the community.
> We should identify just one, or maybe two, releases that allow breakage.
>
> How an update release converted to a "normal" release without
the permission
> to break API is different from an update release?
>
> Mikael[attachment "signature.asc" deleted by Daniel Megert/Zurich/IBM]
> _______________________________________________
> eclipse.org-planning-council mailing list
> eclipse.org-planning-council@xxxxxxxxxxx
> https://urldefense.proofpoint.com/v2/url?u=https-3A__dev.eclipse.org_mailman_listinfo_eclipse.org-2Dplanning-2Dcouncil&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=1UITCR5rxUZHSFczvfaNFK4ymEbEiccRX7VKchpqz0Y&m=pojp-r2HXKysw0ZJ7Esz7wgWi-SGcQ6xlQb8YDl1dA0&s=6DvvtSOb2vfXIBu6UJjeTXVImStLkFPtFAnTlDEeKqY&e=
>
> IMPORTANT: Membership in this list is generated by processes internal
to the
> Eclipse Foundation.  To be permanently removed from this list,
you must
> contact emo@xxxxxxxxxxx to request removal.
>
>
> _______________________________________________
> eclipse.org-planning-council mailing list
> eclipse.org-planning-council@xxxxxxxxxxx
> https://urldefense.proofpoint.com/v2/url?u=https-3A__dev.eclipse.org_mailman_listinfo_eclipse.org-2Dplanning-2Dcouncil&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=1UITCR5rxUZHSFczvfaNFK4ymEbEiccRX7VKchpqz0Y&m=pojp-r2HXKysw0ZJ7Esz7wgWi-SGcQ6xlQb8YDl1dA0&s=6DvvtSOb2vfXIBu6UJjeTXVImStLkFPtFAnTlDEeKqY&e=
>
> IMPORTANT: Membership in this list is generated by processes internal
to the
> Eclipse Foundation.  To be permanently removed from this list,
you must
> contact emo@xxxxxxxxxxx to request removal.
>
>
>
> _______________________________________________
> eclipse.org-planning-council mailing list
> eclipse.org-planning-council@xxxxxxxxxxx
> https://urldefense.proofpoint.com/v2/url?u=https-3A__dev.eclipse.org_mailman_listinfo_eclipse.org-2Dplanning-2Dcouncil&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=1UITCR5rxUZHSFczvfaNFK4ymEbEiccRX7VKchpqz0Y&m=pojp-r2HXKysw0ZJ7Esz7wgWi-SGcQ6xlQb8YDl1dA0&s=6DvvtSOb2vfXIBu6UJjeTXVImStLkFPtFAnTlDEeKqY&e=
>
> IMPORTANT: Membership in this list is generated by processes internal
to the
> Eclipse Foundation.  To be permanently removed from this list,
you must
> contact emo@xxxxxxxxxxx to request removal.



-- 
Alexander Kurtakov
Red Hat Eclipse Team
_______________________________________________
eclipse.org-planning-council mailing list
eclipse.org-planning-council@xxxxxxxxxxx
https://urldefense.proofpoint.com/v2/url?u=https-3A__dev.eclipse.org_mailman_listinfo_eclipse.org-2Dplanning-2Dcouncil&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=1UITCR5rxUZHSFczvfaNFK4ymEbEiccRX7VKchpqz0Y&m=pojp-r2HXKysw0ZJ7Esz7wgWi-SGcQ6xlQb8YDl1dA0&s=6DvvtSOb2vfXIBu6UJjeTXVImStLkFPtFAnTlDEeKqY&e=

IMPORTANT: Membership in this list is generated by processes internal to
the Eclipse Foundation.  To be permanently removed from this list,
you must contact emo@xxxxxxxxxxx to request removal.