incubator-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <>
Subject [Incubator Wiki] Update of "ReleaseChecklist" by MarvinHumphrey
Date Mon, 09 Dec 2013 04:35:44 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Incubator Wiki" for change notification.

The "ReleaseChecklist" page has been changed by MarvinHumphrey:

Migrate draft manifest proposal to Incubator website.  Add optional checklist items.

  = Release manifest usage proposal =
+ Moved to [[]].
- The idea is for the podling's release manager to use this as follows:
-   * Once a release is ready, create such a manifest at$PODLING
-   * Drive the vote on the podling's dev list, reviewers update the manifest accordingly
-   * Bring the vote to general@incubator.a.o, pointing to the existing manifest
- For both votes, +1s in the manifest are added to the [VOTE] thread votes. 
- A given (to be defined) number of documented reviews in the manifest is required for the
release to be approved.
- Release manifests are kept forever in svn, moved to an "archive" subfolder of $PODLING to
make their status clear. 
  = Release manifest example =
+ Moved to [[]].
- {{{
- == Apache Release Manifest =============================================
- Project: Apache Bar
- Release: apache-bar-incubating-0.0.1
- Release manager: Foo Barzinsky (foo)
- Creation date: 2013-12-02
- Status: (vote in progress/canceled/released)
- TODO: add link to an explanation page under
+ = Optional release checklist items =
- == Reviewers and release votes =========================================
- * Foo Barzinsky (foo): Bar project mentor: +1
- * Leo DaVinci (leo): Bar PPMC member: +1
- * Chris Colombo (chris): ASF member: -1 for now:
-     RI 3.4 is unclear, waiting for reply
+ Projects may wish to augment the default checklist in the release manifest with their own
custom items.  Here are some suggestions.
- == Contents =============================================================
- apache-bar-incubating-0.0.1-src.tar.gz + .asc and .sha files
- SHA(apache-bar-incubating-0.0.1-src.tar.gz)= 49ab27e43215d7e45b6f233bb5d5041fcab11d37
+ (This page could potentially supplant [[]]
as a repository for best practice tips.)
- == Review Items =========================================================
- Use "RI m.n" to refer to these elsewhere.
+ ----
- Reviewers sign each item with their Apache ID to indicate that they have
- reviewed and found it ok. 
+  RAT report clean.:: To assist license header checking, some projects use RAT -- possibly
running it via Maven or another build tool.
- Reviewers don't need to look at all items, as long as there's sufficient 
- coverage of each item the release can go out.
- Comments signed with a reviewer's Apache ID are also fine.
+  Change log clean.:: If the project provides release notes, such as in a CHANGES file, make
sure that the file is up-to-date.
+  All copyright dates current.:: If there are copyright dates in files other than NOTICE,
ensure that these are up to date.
- 1.1 Checksums and PGP signatures are valid.
-     Reviewers: foo, leo, chris
+  Issue tracker clean for release version.:: Make sure there are no open issues which should
block the release.
- 1.2 Each expanded source archive matches the corresponding SCM tag.
-     Reviewers: foo, leo, chris
+  Extended tests pass.:: Some projects may have an optional set of tests which are more expensive
to run.  Just before a release is as good a time as any to see whether they pass.
- 2.1 Build instructions are provided, unless obvious
-     Reviewers: foo, chris
-     Comments: (foo) Somewhat terse, please expand for next release
+  Build succeeds on platforms X, Y, Z.:: Test that the release builds successfully on all
target platforms.
- 2.2 Build is successful including automated tests.
-     Reviewers: foo, chris
+  Documentation build clean.:: If the documentation is built as part of the release preparation
process, ensure that it built correctly.
- 3.1 DISCLAIMER is correct, filenames include "incubating".
-     Reviewers: foo, chris, leo
+  Downstream distributions build successfully.:: If the project provides direct support for
downstream distributors (Maven, Debian, CPAN, PyPI, etc), ensure that whatever support is
provided works as intended.
- 3.2 Top-level LICENSE and NOTICE are correct for each distribution.
-     Reviewers: foo, chris, leo
+  Binary release does not contain redundant dependency archives.:: Avoid wasting bandwidth
and space for the sake of mirrors, users, and other downstream consumers.
- 3.3 All source files have license headers where appropriate.
-     Reviewers: foo, chris, leo
- 3.4 The provenance of all source files is clear (ASF or software grants).
-     Reviewers: foo, leo
-     Comments: (leo) See BAR-1234 for software grants info
- 3.5 Dependencies licenses are ok as per
-     Reviewers: foo, leo, chris
- 3.6 Release consists of source code only, no binaries.
-     Reviewers: foo, leo
- == Additional Notes =====================================================
- (free-form reviewer's notes)
- }}}

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message