Introduction

Apache releases consist of the source code of a (sub) project - a.k.a. the artifacts - packaged and signed by the Release Manager (RM) and voted on by contributors to the project. The project's PMC members cast binding votes, everyone else is encouraged to help test the release and report their findings by adding their vote and comments. More information on voting in the Apache organisation can be found here. The artifacts that are being voted upon are collectively referred to as the Release Candidate (RC). In order to make sure that the release meets the standards set by the project and Apache release policies the RC is voted on with a Majority Approval vote.

The Release Process

The release process consists of the following phases:

  1. Development
  2. Feature Freeze
  3. Stabilization/Testing
  4. RC cycle(s)

The Development Phase

The development phase consists of developers committing code to the develop branch of a Git repo. The Apache Flex project uses "Commit then Review", Continuous Integration (CI) Servers and automated testing servers to try to ensure code and documentation quality.

The Feature Freeze

At some point a committer will volunteer to be the Release Manager. The RM is encouraged to check with the community if enough people are interested in helping out, to avoid investing a lot of time but ending up with less than the minimal number of votes needed to release. The RM will send an email to the dev@ list with "[LAST CALL]" in the subject, providing at least a week - but for emergency bug-fix releases, less is OK - before the creation of the release branch. Together with the community, the RM will decide what features and fixes from the develop branch will be included in the release branch. This is effectively a "Feature Freeze" because after this point no new features, and only fixes for important issues, may be committed to the 'release' branch. Any additions to the release branch fall under "Commit then Review", therefor any committer has the right to veto any change made to the release branch.

Regular development can continue on the 'develop' branch.

Once the 'release' branch is created, the RM is responsible for adding a job to the CI and testing setups (Jenkins and Mustella) in order to safeguard stability and to avoid regressions. The RM is welcome to enlist the help of other community members to add those jobs. The result of the CI job should be a complete set of release artifacts minus the PGP signatures. The automated testing server should verify that all tests pass. The RM is welcome to enlist the help of other community members to get the tests to pass. Once that happens, it is time for the testing phase.

The Testing Phase

In the testing phase, the RM will send an email to the dev@ list with "[DISCUSS] Release <Product> <Version>" (e.g. "[DISCUSS] Release Apache Flex SDK 4.14.0") in the subject that calls on the community to test the artifacts available on the CI server. Any issues found should be reported in the DISCUSS thread. The RM or any participant should take care to spin off issues that require lengthy discussion into their own threads. Special care should be given to the documentation - especially the legal bits - as this has been an area of contention in the past. Any issues committers find may be fixed and committed to the 'release' branch. Non-committers are welcome to lobby in the DISCUSS thread for fixes to issues they find.

Busy participants are encouraged to mention in the DISCUSS thread that they plan to test the release branch at a later date, so the RM has an idea of who to expect feedback from.

The RC Phase

Based on the DISCUSS thread, and maybe after some asking and pleading, the RM will decide that the release branch is of sufficient quality to give a vote a good chance of passing. Only then will the RM create an RC and call for a vote with a VOTE thread. As most, if not all, of the testing and vetting of the code and documentation has already been done, this should really be the only RC. This means that only a VOTE thread is needed. If any issues are still found, they can be discussed on the original DISCUSS thread. At this stage only issues with significant negative impact, such as problems with signatures, previously undiscovered licensing error, a security issue, or a bug that will hit a lot of users should cause the RM to discard the RC. Anything else should have been brought up during the testing phase, and any changes/fixes related to those issues should go into develop branch for the next release.

  • No labels

1 Comment

  1. Erik de Bruin

    Moved the comments that were in the article to their rightful place: the Comments. Here is the first bunch all together:

    The Small Print

    All votes mentioned on this page are as defined on the official voting page here.

    Issues

    1. (Justin) How is it decided (without taking a vote) if an issue is blocking or not? What if the blocking issue is only considered a blocker by a one or two PMC members? To me this implies that blockers are vetoes and consensus is required for a release and this is against Apache policy.
    -- (Harbs) Not an issue. We discuss it like rational adults. Most of us can come to an agreement without resorting to voting on everything. If there's a point of contention, only then would it be necessary to call a vote.
    -- (Om) If I think an issue is a blocker, I bring it up in the discuss thread and say 'Hey, this seems pretty serious.  Can we make sure we fix this before we ship?'  It is up to the Release Manager to accept my plea or not.  If he/she does, then the issue becomes a de-facto blocker.  Of course, the RM has no obligation to wait because he/she might not think it is terribly important.  Which means that I have to wait until the next release to see the bug fixed.  Note that there is no way or means for me to veto the release.  No Apache policy is broken.
    -(Justin) Thanks Om for the clarification but this is not what happened on the TourDeFlex release, I as RM disagreed with a blocker but was unable to call a vote until it was resolved.
    -    (Harbs) What do you mean "unable to call a vote"? What was stopping you?
    -(Justin) My understanding of the then (undocumented) process that you were not allowed to  make a RC when there was a blocking issue. When I asked for advice on the list how to resolve the deadlock no one suggested making a RC and calling a vote.

    2. Given the currently lengthy time between releases I would suggest that is at the RM discretion.

    -- I disagree. The whole point of cutting the release from the development branch is that it leaves the development branch available for more work. This is how the "successful git model" is described and we've all agreed on this already.

    3. Issues don't have to be fixed, they need to be discussed and depending on user impact decided if they will be fixed in this release, a future release or not at all. Releases don't need to be perfect, just better than the last release.

    -- There's a difference between "should" and "must". Issues "should" be fixed if reasonable.

    4. How is this determined? Isn't deciding via majority approval voting a lot simpler?

    -- (Harbs) Again, simple discussion is sufficient unless there's disagreement. If there's disagreement, a vote can always be held.
    -- (Om) Remember that the develop branch should be always ready to be released.  By extension, a release branch, which is cut from develop should be ready to release.  The RM gets to make the call when to release.

    5. One very long thread is probably going to make it harder to follow what going on not easier.

    -- (Harbs) Let's try it and see.
    -- (chrsmrtn) I too have a slight concern over this, as my mind set is still tied into the "multi-RC" way (i'm avoiding using 'old way' on purpose). I agree with Harbs that we should try and see. I do see a benefit here of not having to review an old RC thread when a new one pops up to get myself caught up.

    6. Probably against Apache policy and sounds a little more like the benevolent dictator model, I think it needs to be the PMC that decides not the RM - also see point 1.

    -- (Harbs) Nope. If the policy is that only bug fixes are accepted, this is fine. Anyone can veto a commit, and no one is being forced to vote for the release. If there's a majority vote, the release is valid.
    -- (Om) Not against any Apache policy.  The RM can do whatever they want to make sure a release branch is stable.  They can even simply decide to drop the RC and not release at that point in time.  Anyone else can become the RM the next day and pick it up.
    -- (chrsmrtn) I read this last line as a "in summation". So it was speaking to the previously stated ideas of not accepting enhancements and making sure blocking issues that were brought up were addressed by majority. That being either a decision or by vote. Really though we probably wont a "in summary" statement at the end of the official outline that may come out of this. Of course that will come in do time, and not needed to be done right now. We are still working out the details (smile)