DD 0.9 release has been following the Europa milestones for the purpose of getting into practice of regular release cycles. For reference, see the [[Europa Simultaneous Release]],

+

''DD 0.9'' release has been following the Europa milestones for the purpose of getting into practice of regular release cycles. For reference, see the [[Europa Simultaneous Release]],

−

in particular the [[Europa_Simultaneous_Release#Milestones_and_Release_Candidates | Milestones and Release Candidates]]. However, aside from releasing on milestone dates, DD 0.9 release has not been following any of the other release guildelines intentionally, since the technology features have been, and are being developed continually through the ramp down cycle of Europa.

+

in particular the [[Europa_Simultaneous_Release#Milestones_and_Release_Candidates | Milestones and Release Candidates]]. However, aside from releasing on milestone dates, ''DD 0.9'' release has not been following any of the other release guidelines intentionally, since the technology features have been, and are being developed continually through the ramp down cycle of Europa. Also, we expect the ''DD 0.9'' release to be quickly superseded by ''DD 1.0M1'' in both features and stability. Given all that, we can treat the ''DD 0.9'' release also as practice of the release process rather than as a serious product release.

−

Instead of following the standard Europa ramp down policy from above, DD 0.9 ramp down will be the following:

+

Instead of following the standard Europa ramp down policy from above, ''DD 0.9'' ramp down will be the following:

−

* TODO...

+

* We label HEAD as of 5-31-07 and use it as our branch point for 0.9 release.

−

+

* Create a new version label ''R0_9'' and apply it on top of the ''v0_9_0-RC2-20070530'' version label.

−

+

* Create a new branch ''R0_9_maintenance'' and base it on the ''R0_9'' label.

−

''Previous Content, still need to be refactored''

+

* Continue feature development in HEAD.

−

Typically the last week of a Milestone is for testing, and fixing only regressions and P1 or blocking defects.

For milestones, the component lead (or delegate) is enough to review and approve a bug.

+

−

+

−

For M6, we plan to be functionally and API complete and the remaining Release Candidates are for (only) fixing bugs, or fixing release required items (such as version numbers, licensing, etc.).

+

−

+

−

From M6 to RC1 on May 18th, we expect each component lead (or delegate) to review and

+

−

verify their teams' bugs.

+

−

+

−

After the first RC is produced, other RCs will be produced, if needed, every week.

+

−

+

−

After the first RC is produced, the time for general functional improvements is long past. The following describes the types of bugs that would be appropriate:

+

−

<ol>

+

−

* A regression

+

−

* A P1 or P2 bug, one that is blocking or critical, and some cases of major severities.

+

−

* Documentation and PII files are exceptions to the normal PMC required review, since there is little chance of that breaking anything, though it is still expected to be complete by M6, and remaining work to be only documentation fixes (that is, no refactoring of plugins, build changes, etc, without PMC review and approval).

+

−

* In addition to a bug meeting the above priority/severity conditions, there should be a simple, safe, well understood fix that is well isolated from effecting other components, that doesn't affect API or adopters, that has been well reviewed and well tested.

+

−

* As each Release Candidate passes, the criteria for weighing the benefit-to-risk ratio criteria gets higher and higher, and as such requires a larger number of PMC members to review.

+

−

<ol>

+

−

* May 18th, RC 1 produced

+

−

:After the 18th, besides the normal component team review, at least 1 PMC member must also review and vote +1 after reviewing the bug for appropriateness and risk.

+

−

* May 25

+

−

* June 1

+

−

:After June 1, besides the normal component team review, at least 2 PMC members must also review and vote +1 after reviewing the bug for appropriateness and risk.

+

−

* June 8

+

−

* June 15

+

−

:After the 15th, besides the normal component team review, at least 3 PMC member must also review and vote +1 after reviewing the bug for appropriateness and risk.

+

−

* June 22

+

−

:Do zip, update, site preparations

+

−

* June 29

+

−

:Release

+

Latest revision as of 11:36, 31 May 2007

Under Construction

DD 0.9 release has been following the Europa milestones for the purpose of getting into practice of regular release cycles. For reference, see the Europa Simultaneous Release,
in particular the Milestones and Release Candidates. However, aside from releasing on milestone dates, DD 0.9 release has not been following any of the other release guidelines intentionally, since the technology features have been, and are being developed continually through the ramp down cycle of Europa. Also, we expect the DD 0.9 release to be quickly superseded by DD 1.0M1 in both features and stability. Given all that, we can treat the DD 0.9 release also as practice of the release process rather than as a serious product release.

Instead of following the standard Europa ramp down policy from above, DD 0.9 ramp down will be the following:

We label HEAD as of 5-31-07 and use it as our branch point for 0.9 release.

Create a new version label R0_9 and apply it on top of the v0_9_0-RC2-20070530 version label.

Create a new branch R0_9_maintenance and base it on the R0_9 label.

Continue feature development in HEAD.

With +1 vote from PMC, commit fixes to P1 bugs to R0_9_maintenance branch.