Changes between Version 2 and Version 3 of ReleaseProcedure

Timestamp:

Sep 18, 2014, 12:16:42 PM (10 years ago)

Author:

djay

Comment:

--

ReleaseProcedure

@@ -3 +3 @@
 
  * If not already created, create  a wiki page (like this [http://zoo-project.org/trac/wiki/Release/1.3.0/Notes this one] using this scheme: Release/M.m.r/Notes), summarizing changes from the previous release, review the revision log ([http://zoo-project.org/trac/browser/trunk/zoo-project/HISTORY.txt ref.]).
- * That file should include new features, changed features, and depreciated features if any. Changes to the official documentation should be specifically noted along with other items that will cause breaking changes during upgrades. 
+ * 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. 
  * Read the documentation and remove outdated parts.
- * Create beta and release candidate .zip and .tar.gz  then put them on this [http://zoo-project.org/site/Downloads page] (by editing this wiki page: [http://zoo-project.org/trac/wiki/Downloads ref.])
- * Release betas and get feedback until there is no feedback about directly relevant items.
+ * Create release candidate as .zip and .tar.gz  then add them on this [http://zoo-project.org/site/Downloads page] (by editing this wiki page: [http://zoo-project.org/trac/wiki/Downloads ref.])
  * 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.
  * 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).
  * Ensure that release exactly matches something in SVN. Tag and branch appropriately.
- * Update documentation as needed keeping in mind that the versioned documentation on the website pulls from different SVN branches.
- * Put the word out on email list and other locations (news_item@osgeo.org, SlashGeo?, etc)
+ * Update documentation as needed.
+ * Announce on various email list and other locations (news_item@osgeo.org, SlashGeo?, etc)
 
 = Creating an Official Release =
 
-Official releases differ from Betas. Beta testers are advised to download nightly builds and test against them. Release versions lead to an update in documentation and standard tarballs. This is to help future administrators repeatably create releases.
+Release versions lead to an update in documentation and standard tarballs. This is to help future administrators repeatably create releases.
 
  * Double check that the pages from [http://zoo-project.org/ the ZOO-Project.org web site] match the current version.