As the current sprint 'devex #141 December 2017' draws to a close, it is time
to review your unresolved issues!
Some may be done (or will be done soon), but the JIRA(s) need resolution.
Others may need to be pushed to the next milestone (4.5.2.AM3 + 11.2.0.AM3),
to a future .x release, or LATER.
All unresolved issues for 4.5.2.AM2 + 11.2.0.AM2:
All *YOUR* unresolved issues for 4.5.2.AM2 + 11.2.0.AM2:
Once created, you can also begin scheduling your work for the upcoming
sprint, 'devex #142 December 2017'.
* blocker/critical issues: make these your priority work for the next sprint:
move to next version & assign to the next sprint
* other issues that WILL be done in the next sprint:
move to next version & assign to the forthcoming sprint, but lower down
* non-blocker & non-critical issues not for the next sprint:
move to .x (or LATER)
FYI, a new world order is coming to Eclipse. :)
---------- Forwarded message ----------
From: Daniel Megert <daniel_megert(a)ch.ibm.com>
Date: Fri, Dec 1, 2017 at 9:18 AM
Subject: [eclipse.org-planning-council] Fw: [cross-project-issues-dev]
Change in Eclipse SDK release cadence
To: Eclipse Planning Council private list <
----- Forwarded by Daniel Megert/Zurich/IBM on 01.12.2017 15:17 -----
From: Aleksandar Kurtakov <akurtako(a)redhat.com>
To: "issues, Cross" <cross-project-issues-dev(a)eclipse.org>
Date: 01.12.2017 12:48
Subject: [cross-project-issues-dev] Change in Eclipse SDK release
Sent by: cross-project-issues-dev-bounces(a)eclipse.org
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.
cross-project-issues-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
eclipse.org-planning-council mailing list
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(a)eclipse.org to request removal.
Senior Software Engineer, RHCSA
Productization Lead :: JBoss Tools & Dev Studio
IM: @nickboldt / @nboldt / http://nick.divbyzero.com
TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>
@ @redhatnews <https://twitter.com/redhatnews> Red Hat