[Cordova Wiki] Update of "CuttingReleases" by brianleroux

[Apache Wiki <wi...@apache.org>]

Dear Wiki user,

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

The "CuttingReleases" page has been changed by brianleroux:
http://wiki.apache.org/cordova/CuttingReleases?action=diff&rev1=1&rev2=2

  A official source release contains code for each Apache Cordova platform, the documentation and various other artifacts. 
  
  {{{
+ 
-   /
+  /
+  |- NOTICE ...... any additional license info
+  |- bin/ ........ the cordova binaries for building apps!
+  |- doc/ ........ compiled cordova-docs
+  |- keys ........ signing keys
+  |- license ..... the asl
+  |- readme.md ... quick readme
+  |- src/ ........ export all platform src dirs
+  '- version ..... version txt
+ 
-   |-doc/ ........... source documentation
-   |-lib/ ........... platform code for supported operating systems
-   | |-android/
-   | |-bada/
-   | |-blackberry/
-   | |-ios/
-   | |-symbian/
-   | |-webos/
-   | '-windows/
-   |-changelog ..... a changelog compiled from comments and authors
-   |-license ....... the Apache Software License v2
-   |-version ....... release version in plain text
-   '-readme.md ..... release readme
  }}}
  
- == Notifying the Community ==
+ The {{{/bin/}}} is what you want if you want to start building apps with Cordova.
  
- The Apache Cordova community aims to prepare releases monthly. Discussion for a release should happen on the mailing list.
+ {{{
  
- == Packaging a Release for Testing ==
+ /
+ |-android/
+ |-bada/
+ |-blackberry/
+ |-ios/
+ |-symbian/
+ |-webos/
+ '-windows/
  
- TODO
+ }}}
  
- == 
+ == Release Philosophy ==
  
+ The Apache Cordova community aims to prepare releases monthly. Discussion for a release always happens on the mailing list. 
+ 
+ We follow a rolling releases (sometimes called the Train Model) philosophy, which is to say, we value consistent release cadence as a priority over aiming to cram a particular issue, bug or feature to a particular date. Each minor release tends to be loosely themed on a generally agreed upon goal for the project. Bugs always take priority over new shiny. 
+ 
+ Early in the project we stalled on 0.8.0 for almost a year, and as a result our community worked off the edge, making issue tracking very difficult, cascading into a host of predicability and reliability issues, jeopardizing the community. In 2009, when IBM joined the effort with Nitobi, we started releasing once a month, rolling issues over to the next minor.
+ 
+ We have recently, in the past year or so, started tagging Release Candidates about a week before the expected ship for minor release (such as 1.5.0rc1) which tends to tease out more bugs and avoid the embarrassing patch release. (1.4.1 comes to mind.)
+ 
+ === 2012 **Estimated** Release Schedule ===
+ 
+ - 1.6.x, Mar 30
+ - 1.7.x, Apr 30
+ - 1.8.x, May 28
+ - 1.9.x, Jun 25
+ - 2.0.x, Jul 30
+