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.
Every release cycle is divided into the following phases:
| Week | Phase |
|---|---|
| 10-11* | Initial Feature Tagging |
| 12* | Initial Feature Evaluation |
| 1-4 | Development 1 |
| 5 | Mid-Cycle Feature Evaluation |
| 6-9 | Development 2 |
| 10 | Feature Freeze |
| 11 | Bug Fixing 1 |
| 12 | Bug Fixing 2 |
NOTE: Weeks marked * happen during the previous release cycle. This is, the Initial Feature Tagging and Initial Feature Evaluation phases for release cycle N happen during the Feature Freeze and Bug Fixing phases of release cycle N-1.
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.21release, remaining TODO tickets are re-tagged with the1.22tag).
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 during1.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 progresses for 4 weeks as usual.
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_proposals.
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 progresses for 4 more weeks as usual.
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.
Only bug fixing during this phase, with this exception:
A Beta release is produced at end of this phase.
Only bug fixing during this phase, with this exception:
If release can be executed, release ships at the end of this phase. Otherwise, perform pre-release and go back to the Feature Freeze phase.
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 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.
Create a 'work proposal' ticket as described in the 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.
See the Proposals section.
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.
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.
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.
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.
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.
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.