That is, your stuff is due earlier than these table dates! Projects need to deliver a week or two before these "end dates", depending on their chosen, committed offset category (+0, +1, etc). The following table summarizes the most significant Neon dates, but see the subsequent calendar for the important details. Given all these constraints, the exact dates for any particular year are pretty predictable. Feel free to bring up complicated cases for discussion. These sorts of deviations are left to the projects to work out, pair-wise, among themselves. There are many cases where a project might have to deliver pieces of their code a little earlier, if some project depends on it, or a little later if they have a stray dependency. Note that projects choose their own +n category based on major or primary dependencies. Projects are free to have their own schedules as long as they meet the Neon deliverables. The following calendar is the official schedule of the overall Neon Release. The actual time-offset represented by these intervals change over the course of the year of development, being several days at first, but then only one day near the end of the release. Projects themselves decide if they are +0, +1, +2, or +3. They are labeled +0, +1, +2, and +3, with +0 coming first (the Platform) and "+4" coming last (only EPP packages). These delivery times are based on the dependencies between projects. Each project has their deliveries due at times offset from the end-date, so that the project dependencies can come together in a reasonable order. Any end-of-cycle release-candidate (RC) dates are typically one week apart. The milestone dates are at roughly 6 week intervals. The Release is always on the fourth Wednesday of June. Projects that are part of Neon agree to abide by the requirements of the Eclipse yearly Simultaneous Release. 5.1 Interlock of Milestones and Update releases.3.2.4 The Planning Council Mailing List.3.1 Cross-Project Milestone & RC Status Reporting.
0 kommentar(er)
