20,741
edits
Release plan: Difference between revisions
m
→2.10: more lessons learned from the dev list
m (→2.10) |
m (→2.10: more lessons learned from the dev list) |
||
| Line 202: | Line 202: | ||
* a little irritation/frustration was caused due to the conflicting review statements concerning the new radio propagation code [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38905.html] [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38825.html] [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg33692.html] - some of this boiled down to coding style related issues, highlighting the fact that different core developers have different "coding styles" and requirements when reviewing merge requests, because we still lack an official "FlightGear coding style guide" [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38958.html] | * a little irritation/frustration was caused due to the conflicting review statements concerning the new radio propagation code [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38905.html] [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38825.html] [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg33692.html] - some of this boiled down to coding style related issues, highlighting the fact that different core developers have different "coding styles" and requirements when reviewing merge requests, because we still lack an official "FlightGear coding style guide" [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38958.html] | ||
* the [https://gitorious.org/fg/flightgear/blobs/next/scripts/python/nasal_api_doc.py nasal_api_doc.py] script in $FG_SRC/scripts/python should be run as part of the release process, to create an updated doc file for $FG_ROOT/Docs and ship it with each release [http://flightgear.org/forums/viewtopic.php?f=30&t=15133] | * the [https://gitorious.org/fg/flightgear/blobs/next/scripts/python/nasal_api_doc.py nasal_api_doc.py] script in $FG_SRC/scripts/python should be run as part of the release process, to create an updated doc file for $FG_ROOT/Docs and ship it with each release [http://flightgear.org/forums/viewtopic.php?f=30&t=15133] | ||
* We've already got a fairly extensive lead-in time for the release. More testers on more platforms would seem to be the answer. Perhaps we should advertize for testers of those platforms that aren't adequately covered by developers running git? Making a complete package available, not just the binaries would help, as testers wouldn't need to be git-aware. [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38764.html] | |||
* The main area to improve is to distribute release candidates for all platforms earlier - preferably starting immediately after the freeze. That would already give us more time for testing - without extending the actual freeze period.[http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38765.html] | |||
* How about having a test run a week or two in advance, just to make sure we can indeed produce release installers for Win+Mac - and then release the first RC on December 17th/18th or 19th [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38765.html] | |||
* To get to the 3.0 goal sometime in the near future, it's probably a good idea to create a backlog of open items in the wiki and link the release plan document to that. As usual, we don't have to be perfect for a new major release number. But the new features being the reason for the new major number should work reasonably correct. [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38888.html] (also see [[:Category:Developer Plans]]) | |||
==== 2.8 ==== | ==== 2.8 ==== | ||