m(update note about correlation to Changes policy to reflect today's version of the truth)

(10 intermediate revisions by 2 users not shown)

Line 1:

Line 1:

−

Change deadlines happen two weeks before the public release of each Fedora Alpha, Beta, and Final release.

+

''Milestone freezes'' happen two weeks before the public release of each Fedora Alpha, Beta, and Final release. ''Milestone freeze'' is the generic term. The specific milestone freezes are the ''Alpha freeze'', ''Beta freeze'', and ''Final freeze''.

−

At the change deadline, ''pushes'' to the branched development repository are suspended until the release candidate is accepted.

+

== What happens in a ''Milestone freeze''? ==

−

A ''push'' is a release engineering term for moving a package into a particular repository of packages. After a release has been branched, a new or updated package must receive testing feedback via Bodhi before it is allowed into the ''stable branch.''

+

{{admon/note|Historical names|Between Fedora 14 Beta and Fedora 21 Alpha, these were known as '''Change deadlines'''.<ref>See [http://meetbot.fedoraproject.org/teams/fesco/fesco.2010-05-18-19.03.log.html the 2010-05-18 FESCo meeting] for the decision to change the name to ''Change deadline'', and [https://lists.fedoraproject.org/pipermail/devel/2014-September/202650.html this 2014-09 mailing list thread] for the decision to change it back.</ref> Prior to Fedora 14 Beta, they were again called ''Alpha freeze'', ''Beta freeze'' and ''Final freeze''. At earlier times when the milestone names were different, the freeze names naturally corresponded.}}

−

The ''branched development'' repository is the repository of packages that were originally branched from rawhide or have been [[Package_update_HOWTO#Working_with_packages_in_the_stable_branches|updated through the Bodhi process]]. For example, the branched development repository path for {{FedoraVersion|long|next}} is <code>/pub/fedora/linux/development/{{FedoraVersion|number|next}}</code>.

+

At the milestone freeze, ''pushes''<ref>A ''push'' is a release engineering term for moving a package into a particular repository of packages.</ref> from the [[Repositories#updates-testing|''updates-testing'']] repository to the ''stable'' [[Repositories#fedora|''fedora'']] repository for the pending [[Releases/Branched|Branched]] release are suspended until the [[QA:SOP_compose_request#Release_candidates|release candidate]] is accepted.

−

== Alpha and Beta public releases ==

+

== What repositories and releases does a ''milestone freeze'' affect? ==

−

At the change deadlines for Alpha and Beta, pushes to the ''branched development'' repository (e.g. <code>/pub/fedora/linux/development/{{FedoraVersion|number|next}}</code>), are suspended until the Release Candidate has been successfully tested and staging has started to the mirrors.

+

The freeze applies only to Branched (the pending pre-release), and only to the ''stable'' [[Repositories#fedora|''fedora'']] repository. Packages can still be submitted to [[Repositories#updates-testing|''updates-testing'']] in the usual manner, and other releases are not affected at all.

−

; What can be pushed into the branched development repository?

+

== When does each ''milestone freeze'' end? ==

−

: Only blocker bugs of a public release (critical path or not) can be pushed to a ''branched development'' repository during this interim period, until the Release Candidate is ready to stage to mirrors.

+

−

; Where should other changes be pushed?

+

Each milestone freeze ends shortly after the milestone release is approved for release at a [[Go No Go Meeting]]. After Alpha and Beta releases, the [[Repositories#fedora|''fedora'']] repository is once more opened to ''stable'' pushes under the [[Updates Policy]]. Packages marked as ''stable'' through the usual [[Bodhi]] process between Alpha release and ''Beta freeze'' will appear in the Beta release, and packages marked as ''stable'' between Beta release and ''Final freeze'' will appear in the Final release.

−

: Pushes may continue to the ''updates-testing'' repository.

+

−

== Final public release ==

+

== What happens to updates that go ''stable'' after the ''Final freeze''? ==

−

After the change deadlines for the Final release no more updates are made to the ''branched development'' repository (e.g. <code>/pub/fedora/linux/development/{{FedoraVersion|number|next}}</code>). The only exceptions are [[QA:SOP_blocker_bug_process|accepted blocker bugs]] and [[QA:SOP_nth_bug_process|nice to have bugs]].

+

Once the ''Final freeze'' takes effect, the release package set is decided except for blocker and freeze exception bug fixes. There is no further window for other packages to appear in the Final release ''per se''. Other updates submitted for ''stable'' status during this period are queued and, once the Final release is approved, are pushed not to the [[Repositories#fedora|''fedora'']] repository but to the [[Repositories#updates|''updates'']] repository.

−

All updates after this time are considered ''zero day updates'' of the release, and are pushed to the ''updates'' repository which is available on the public availability date. For example, the repository for {{FedoraVersion|long|next}} is <code>/pub/fedora/linux/updates/{{FedoraVersion|number|next}}</code>.

+

Packages that meet the requirements for ''stable'' status between Final freeze and Final release day will appear in the ''updates'' repository on the day of release. Such packages are sometimes referred to as ''0-day updates''.

+

+

== How are freeze exceptions proposed and granted? ==

+

+

Exceptions to the ''milestone freezes'' are granted '''only''' through the [[QA:SOP_blocker_bug_process|blocker]] and [[QA:SOP_freeze_exception_bug_process|freeze exception]] policies, to packages that fix ''accepted blocker'' or ''accepted freeze exception'' bugs. If you believe a build should be except from a ''Milestone freeze'', please refer to these pages for details on how and when to propose a bug for ''blocker'' or ''freeze exception'' status.

+

+

== How do ''milestone freezes'' relate to [[Changes/Policy|Changes]]? ==

+

+

The [[Changes]] process for tracking major Fedora development work and the milestone freezes are not inherently related. The reason for milestone freezes is to reduce "churn" in the ''stable'' package set from which a milestone is being composed in order to make the release compose and [[QA:Release_validation_test_plan|validation]] processes manageable. The need for these freezes arises regardless of other details of the development process.

+

+

However, the nature of a ''milestone freeze'' makes it natural for some Change policy dates to coincide with them. Change development work will not usually qualify for a freeze exception, so if a Change is expected to reach a certain level of quality by the release of a particular milestone, it is effectively the case that it must reach that level of quality by the freeze date for that milestone.

+

+

For this reason, the [[Changes/Policy#For_Developers|Changes Checkpoint #3]] date occurs on the same day as the Beta freeze.

+

+

== Where can I find the rules for updates outside of ''milestone freezes''? ==

+

+

The policy for ''pushes'' from ''updates-testing'' to ''fedora'' for Branched releases outside of the ''Milestone freezes'' is the [[Updates Policy]].

+

+

== Where can I find an overview of the full development process? ==

+

+

The [[Fedora Release Life Cycle]] provides a good overview and a handy jumping-off point for more details on the complete Fedora release process.

+

+

<references/>

[[Category:Release Engineering SOPs]]

[[Category:Release Engineering SOPs]]

+

[[Category:Package Maintainers]]

+

[[Category:Policy]]

Latest revision as of 19:24, 1 October 2014

Milestone freezes happen two weeks before the public release of each Fedora Alpha, Beta, and Final release. Milestone freeze is the generic term. The specific milestone freezes are the Alpha freeze, Beta freeze, and Final freeze.

Historical namesBetween Fedora 14 Beta and Fedora 21 Alpha, these were known as Change deadlines.[1] Prior to Fedora 14 Beta, they were again called Alpha freeze, Beta freeze and Final freeze. At earlier times when the milestone names were different, the freeze names naturally corresponded.

The freeze applies only to Branched (the pending pre-release), and only to the stablefedora repository. Packages can still be submitted to updates-testing in the usual manner, and other releases are not affected at all.

Each milestone freeze ends shortly after the milestone release is approved for release at a Go No Go Meeting. After Alpha and Beta releases, the fedora repository is once more opened to stable pushes under the Updates Policy. Packages marked as stable through the usual Bodhi process between Alpha release and Beta freeze will appear in the Beta release, and packages marked as stable between Beta release and Final freeze will appear in the Final release.

Once the Final freeze takes effect, the release package set is decided except for blocker and freeze exception bug fixes. There is no further window for other packages to appear in the Final release per se. Other updates submitted for stable status during this period are queued and, once the Final release is approved, are pushed not to the fedora repository but to the updates repository.

Packages that meet the requirements for stable status between Final freeze and Final release day will appear in the updates repository on the day of release. Such packages are sometimes referred to as 0-day updates.

Exceptions to the milestone freezes are granted only through the blocker and freeze exception policies, to packages that fix accepted blocker or accepted freeze exception bugs. If you believe a build should be except from a Milestone freeze, please refer to these pages for details on how and when to propose a bug for blocker or freeze exception status.

The Changes process for tracking major Fedora development work and the milestone freezes are not inherently related. The reason for milestone freezes is to reduce "churn" in the stable package set from which a milestone is being composed in order to make the release compose and validation processes manageable. The need for these freezes arises regardless of other details of the development process.

However, the nature of a milestone freeze makes it natural for some Change policy dates to coincide with them. Change development work will not usually qualify for a freeze exception, so if a Change is expected to reach a certain level of quality by the release of a particular milestone, it is effectively the case that it must reach that level of quality by the freeze date for that milestone.