# Release Cycle # EFL aims at producing periodic releases of consistent quality. The goal of the release cycle described here is to produce a new release every 3 months (12 weeks), interleaving development periods with testing and bug fixing. ## Phases Every release cycle is divided into the following phases: | Week | Phase | | ------- | ------------------------------------------------------------- | | 10-11* | [Initial Feature Tagging](#Initial_Feature_Tagging) | | 12* | [Initial Feature Evaluation](#Initial_Feature_Evaluation) | | 1-4 | [Development 1](#Development_1) | | 5 | [Mid-Cycle Feature Evaluation](#Mid-Cycle_Feature_Evaluation) | | 6-9 | [Development 2](#Development_2) | | 10 | [Feature Freeze](#Feature_Freeze) | | 11 | [Bug Fixing 1](#Bug_Fixing_1) | | 12 | [Bug Fixing 2](#Bug_Fixing_2) | > **NOTE:** > Weeks marked * happen during the **previous** release cycle. This is, the [Initial Feature Tagging](#Initial_Feature_Tagging) and [Initial Feature Evaluation](#Initial_Feature_Evaluation) phases for release cycle N happen during the [Feature Freeze](#Feature_Freeze) and [Bug Fixing](#Bug_Fixing_1) phases of release cycle N-1. ### Initial Feature Tagging Starting in the last 3 weeks of the previous release cycle, for 2 weeks tickets with TODO priority are created (or re-tagged) with the milestone tag of the next cycle, and the ``work_proposal`` tag is appended. Major features also receive the ``major_changes`` tag. > For example, during the last 3 weeks of the ``1.21`` release, remaining TODO tickets are re-tagged with the ``1.22`` tag). ### Initial Feature Evaluation After this period, a 1 week multi-vote is created on Phabricator to evaluate all proposals tagged with ``work_proposal``. Core developers vote to **defer** TODO tickets to a later release. > For example, while finishing work on ``1.21``, you have to vote for those tickets you do **NOT** think should be worked during ``1.22``). This aims at promoting discussion about work items, and reviewing of anything which might be too radical to accomplish within the next release cycle. Any TODO item which receives 5 or more votes from #committers is **deferred** to a later release cycle (That work is not merged into master during this release cycle). ### Development 1 Development progresses for 4 weeks as usual. ### Mid-Cycle Feature Evaluation Feature development halts for 1 week (bug tickets on the "urgent" work board are handled as time allows). Two polls are created to re-evaluate the features currently under development: * A vote to review existing ``active_work_proposal``s. It may be the case that unforeseen difficulties arise in development, so this creates a process by which a work item can be officially deferred. * A vote to review other TODO items which are not yet accepted. If some items are deferred then there may be extra time available, or perhaps a proposal for implementing a feature has been reworked to make it fit into the release better. ### Development 2 Development progresses for 4 more weeks as usual. ### Feature Freeze Only bug fixing from now on, with these exceptions: * Any "major" feature patches submitted before the freeze begins can still be reviewed and landed. * Any "major" feature patches submitted after the freeze are unconditionally deferred until the next release cycle. * Any "small" feature patches can be landed (with 3+ reviews and no rejects after being on Phabricator for 48+ hours). > An Alpha release is produced at end of this phase. ### Bug Fixing 1 Only bug fixing during this phase, with this exception: * No features of any kind may be landed unless they are "small" and are required in order to fix an urgent (high/showstopper priority) bug. > A Beta release is produced at end of this phase. ### Bug Fixing 2 Only bug fixing during this phase, with this exception: * No features of any kind may be landed unless they are "small" and are required in order to fix an urgent (high/showstopper priority) bug. **If release can be executed, release ships at the end of this phase.** Otherwise, perform pre-release and go back to the [Feature Freeze](#Feature_Freeze) phase. ## Proposals If you want a feature to be added to EFL, you write a proposal ticket for it in Phabricator. Proposal tickets should: * Include a description of the work which you are planning to do. * If the work is complex, or the reason for it is non-obvious, explanations should be provided to justify the work. * Be tagged with ``efl`` (or a sub-project), ``work_proposal``, and the release cycle you want it merged into master (e.g. ``1.22``). The [Initial Feature Evaluation](#Initial_Feature_Evaluation) phase will then include your proposal in the voting. During the voting weeks, proposals being evaluated will be tagged ``voting`` by the release team. During the development weeks, proposals being worked on will be tagged ``active_work_proposal`` by the release team. ## FAQ ### I didn't write a proposal for work that I am planning to do, what happens now? Create a 'work proposal' ticket as described in the [Initial Feature Tagging](#Initial_Feature_Tagging) phase. 5 weeks from now, a second voting session will occur, and any proposals which are not rejected will become features of the next release cycle. ### What is a proposal? See the [Proposals](#Proposals) section. ### Why proposals? Previously, EFL releases were like a giant pile of unrelated and uncoordinated work. There was no big picture and nobody knew what anyone else was doing. This methodology provides solutions to these issues and allows for a framework within which contributors can work cooperatively on features for each release. ### When do I need a proposal? If you are planning to do work which is large or requires a lot of changes, you should create a proposal. This may include things like major refactoring projects, adding features affecting multiple components, adding a feature which fundamentally changes how EFL works/runs/builds, or any other item which may be considered controversial. ### When do I not need a proposal? If you are adding a trivial feature (e.g., a get method for a property) or fixing bugs, you probably do not need a proposal. If in doubt, create one anyway in order to avoid conflict. ### What happens to already-submitted patches which implement features? Patches implementing features which were submitted on Phabricator prior to the 1.21 release will not require proposals and can be reviewed/accepted normally. This is a one-time acceptance to avoid creating more work for people who had completed projects prior to the current development cycle. ### What do I do about my project for the next 5 weeks if I did not submit a proposal? A proposal is for merging features into the master branch, not for working on features. Features should be worked on at any time regardless of proposals, but they are not merged to the master branch and shipped in releases until a proposal for the project has been accepted. ### So I can work on my tasks without a proposal? Yes, though it should be noted that reviews of the eventual proposal may require a rewrite of the implementation in order to comply with those reviews and have the feature merged. For this reason it is highly advised to either submit the proposal prior to beginning work or to expect that the existing implementation be used as an example that can be refined before being merged.