Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: updated vote guidelines

...

  • A developer posts a message stating it's time asking the list whether there are any objections to locking down for a release for a given component. If there is a lead for the given component then the lead should make the post or the lead should be consulted before the post to prevent any potential confusion.
  • If agreed, at At this point no more issues can be assigned a fix version corresponding to the release.
  • When the count goes to zero the voting for the release starts
  • There should be plenty of opportunity for people to request rescheduling of issues before the vote begins. No rescheduling should be discussed in the vote unless it is exceptional circumstances.
  • An RC is created and is used for people to vote on (see below)
  • The vote must last at least 72 hours to give everyone a chance to give feedback.
  • If there is a regression or other problem with the release, the vote is suspended until it is fixed. Other issues may be brought up during that period. Once those are resolved, the vote starts over (another 72 hours, new RC, new vote thread).72 hours later the release occurs, or we discuss why the release was voted down

At some point we might even be able to automate this will a little voter app, or use the one we use for board elections. Still visible but much better audit trail.

...

  • TODO We need a staging artifact repository where the RCs can be placed so that failed RC attempts don't pollute a release artifact repository
  • TODO We need a reliable way of moving the successful RC from the staging repository to the release repository. This is an intended feature for the Repository Manager but we may need a stop-gap solution until the Repository Manager is ready for production use.
  • TODO We need to ensure that the RC that gets promoted as the release is not rebuilt. At the same time we need to provide a way to identify what version a user is running (be it a RC1, RC2, etc). One solution is to use a build# so that a maven2 version is always made of both a Version a build number. For example you would have "Maven 2.1 Build # 1353" which would be RC1 and then "Maven 2.1 Build # 1450" which would be RC2 which gets promoted as the 2.1 release.

In the interim, we use timestamped builds from CI for distributions, and timestamped snapshots for plugins.

Soak period for RCs

RCs should be circulated for no less then three days so that we can accurately determine if there are any defects present. When you are ready to release the RC use the release plug-in:

...