As always, we, the Planning Council (PC), commit to finalizing the Neon Plan and Requirements by M4. And we have now done that. Nothing is too different but there are some differences. So read carefully and keep this note for reference.
- The Plan [1]: milestones are similar to previous years, but after the release in June, we will plan on having 3 "update releases" instead of 2, as we have done in previous years. (The Mars plan remains the same: one more update release in February.) Besides "increased frequency" we also had the goal of having the update releases more evenly spaced throughout the development year, basically "one per quarter". It turns out to be easiest, we believe, to tie the update releases to the same day as three of the "Neon+1" milestones [2]. More specifically, that is Milestones 2, 4 and 6 in September, December, and March. See the Plan Section "Update Releases" [3] for more detail. (And, please, read the whole plan [1], especially if new to the Simultaneous Release.) We recognize this will be "more work" for most projects, but keep in mind exactly how much work is done for each update release is still up to each project. Some may barely do "minor service", some may have "new features". It is up to the project. But you can not have "breaking changes", except in rare circumstances. One implication of this change is that the last Update Release will come after EclipseCon NA, in 2017, assuming EclipseCon is scheduled similar to how it is currently. While not relevant for a while, there are other changes for dates related to the Update Releases: There will no longer be a "warm-up RC1" that is done two weeks early. Instead, we will just start off with a "real RC1" only one week before RC2. This is because we, the PC, feel projects have matured enough at this process to no longer need a warm-up RC, not to mention we have a compressed schedule. Similarly, while less important for Neon than for Neon+1, in the future we will no longer have a "two week window" for the first three milestones. We will instead have a one week window all the time. Again, this is due to the maturity of Eclipse projects, plus our desire to have more uniformity in the schedules. This does not effect Neon, since we are already moving to the 1 week window as of right now! for M4. (Everyone "in" by Wednesday, right?) - The requirements [4]: They are the same, except for two additions. You can find them in the release document by searching for "[added 12/2015, for Neon]". But I will paste them below, for a quick read. I think the reasons for them are fairly obvious, if you've followed the many discussions we've had on this list and in bugs for years, but if any one has any questions, I'll address in a separate note, instead of making this note more wordy. And, again, please read whole document, even if experienced. = = = = [added 12/2015, for Neon] While part of the mechanics of contributing to the build, it is required that any contribution to the Simultaneous Release repository be done by a unique change to the b3aggrcon file. There are two ways to do this. First, your contribution repository can point to a simple repository where you know for sure there is only one version of your contribution available. Second, your contribution repository can be a composite repository but then you name exactly which versions to include. That is you need to specify all 4 version fields. You can, of course, do both methods, simple repository and name exact versions if you want the safety of that redundancy. [added 12/2015, for Neon]. Note: If a jar is already signed by the Eclipse certificate, then it must not be re-signed by projects for the release train. = = = = As always, questions are welcome. In the mean time ... back to getting M4 done! Thank you all for participating and contributing to Eclipse. [1] https://wiki.eclipse.org/Neon/Simultaneous_Release_Plan [2] feel free to suggest a name for Neon+1, in Bug 483685 [3] https://wiki.eclipse.org/Neon/Simultaneous_Release_Plan#Update_Releases [4] https://wiki.eclipse.org/SimRel/Simultaneous_Release_Requirements
_______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
