Changeset 701
- Timestamp:
- Jun 30, 2015, 1:58:17 PM (9 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
branches/PublicaMundi_David-devel/docs/contribute/release.rst
r700 r701 4 4 ================= 5 5 6 * Any ZOO-Project commiter can ask for a release by asking the ZOO-Project PSC and pointing a release manager. This last will then vote for accepting both the manager and the release procedure to happen. 7 * If not already created, create a wiki page (like this `this one <http://zoo-project.org/trac/wiki/Release/1.3.0/Notes>`_ using this scheme: Release/M.m.r/Notes), summarizing changes from the previous release (extracted from the `revision log <http://zoo-project.org/trac/browser/trunk/zoo-project/HISTORY.txt>`_). 8 * That file should include new features, changed features, and deprecated features if any. Changes to the official documentation should be specifically noted along with other items that will cause breaking changes during upgrades. 9 * Read the documentation and remove outdated parts. 10 * Create release candidate as .zip and .tar.bz2 then add them on this `page <http://zoo-project.org/site/Downloads>`_ (by editing this `wiki page <http://zoo-project.org/trac/wiki/Download>`_) 11 * Cut a release candidate once you think that everything is in order. Announce the release candidate for review for at least 1 week. In this period of time, it is also appropriate for you to deploy in production since you are asserting that it is stable and (significant) bug free. Publish a specific revision with this. 12 * If significant bugs are reported, fix and cut a new release candidate. If no major bugs, then announce that the release candidate has officially been promoted to the official release (if you want, you can do this with a motion and support of the PSC). 13 * Ensure that release exactly matches something in SVN. Tag and branch appropriately. 14 * Update documentation as needed. 15 * Announce on various email list and other locations (news_item@osgeo.org, SlashGeo, etc) 6 The ZOO-Project release procedure is commonly defined by the following 7 rules: 8 9 * Any ZOO-Project commiter can ask for a release by asking the 10 ZOO-Project PSC and pointing a release manager. This last will then 11 vote for accepting both the manager and the release procedure to 12 happen. 13 * If not already created, create a wiki page (like this `this one 14 <http://zoo-project.org/trac/wiki/Release/1.3.0/Notes>`_ using this 15 scheme: Release/M.m.r/Notes), summarizing changes from the previous 16 release (extracted from the `revision log 17 <http://zoo-project.org/trac/browser/trunk/zoo-project/HISTORY.txt>`_). 18 * That file should include new features, changed features, and 19 deprecated features if any. Changes to the official documentation 20 should be specifically noted along with other items that will cause 21 breaking changes during upgrades. 22 * Read the documentation and remove outdated parts. 23 * Create release candidate as .zip and .tar.bz2 then add them on this 24 `page <http://zoo-project.org/site/Downloads>`_ (by editing this 25 `wiki page <http://zoo-project.org/trac/wiki/Download>`_) 26 * Cut a release candidate once you think that everything is in 27 order. Announce the release candidate for review for at least 1 28 week. In this period of time, it is also appropriate for you to 29 deploy in production since you are asserting that it is stable and 30 (significant) bug free. Publish a specific revision with this. 31 * If significant bugs are reported, fix and cut a new release 32 candidate. If no major bugs, then announce that the release 33 candidate has officially been promoted to the official release (if 34 you want, you can do this with a motion and support of the PSC). 35 * Ensure that release exactly matches something in SVN. Tag and branch 36 appropriately. 37 * Update documentation as needed. 38 * Announce on various email list and other locations 39 (news_item@osgeo.org, SlashGeo, etc) 16 40 17 41 Creating an Official Release
Note: See TracChangeset
for help on using the changeset viewer.