flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bertrand Delacretaz <bdelacre...@apache.org>
Subject [TTH] Why do you need release candidates?
Date Sat, 06 Dec 2014 09:05:21 GMT
Hi Flex team,

Reviewing your activities to try and help this community run in a
smoother way, I'm wondering why you need release candidates.

Those were useful during your Apache incubation, to allow "total
strangers" who don't have the right tools for example to review your
releases, but in a small team that does have the appropriate tools to
verify things form source I'm not sure they are worth the effort.

Release candidates create a lot of work for the release manager, and
require a lot of coordination between yourselves to find out when to
create another one, cast multiple votes or argue about when it's
appropriate to carry votes over, etc.

Based on other projects, I'm suggesting a simpler way of creating your
releases, below.

As usual, this is only my old fart^H^H^H^H experienced Apache member
advice, feel free to take it into account or not.

You might also just try it on one of your releases to see if it works
- it's easy to try.


Here's my suggested release (non-) process:

Designate a Git branch to become the release and create a jira version
number that represents it.

Create small, specific jira issues for things (including integrating
patches from other branches) that prevent the branch from being
released as is, and link those to the release version in jira, so that
simple jira queries show what’s left to do and what's been done.

Setup your continuous integration system to run regularly on that
branch, ideally after every commit.

Ask people to review the branch and create jira issues for anything
wrong with it.

Wait until all jira issues are closed (or rescheduled), prepare the
release artifacts, vote on them and release.

You vote just once, you’re not arguing all the time about where the
release stands (or if you do that’s in or about specific jira issue
which make things clearer), and the release vote passes 99% of the

View raw message