FlightGear wiki

Release plan: Difference between revisions

Page Discussion

Release plan (view source)

Revision as of 23:16, 30 January 2013

249 bytes added ,  30 January 2013
→‎2.10
Line 195: Line 195:
* {{Thumbs up}} Walking through the list of "lessons learned" as part of the "Upcoming release" announcement was useful [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38749.html]
* {{Thumbs up}} Walking through the list of "lessons learned" as part of the "Upcoming release" announcement was useful [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38749.html]
* perform a sync with JSBSim sources before the feature freeze.
* perform a sync with JSBSim sources before the feature freeze.
* {{Thumbs up}} Posting the link to the changelog for the upcoming release helped writing the changelog early, this should also be done for the [[Hardware Recommendations]] and [[Notebooks known to run FlightGear]] pages probably?
* Changelog / Release Announcement:
** {{Thumbs up}} Posting the link to the changelog for the upcoming release helped writing the changelog early, this should also be done for the [[Hardware Recommendations]] and [[Notebooks known to run FlightGear]] pages probably?
** {{Thumbs up}} The changelog can be easily written by using "git log", searching the issue tracker and by going through the last 6 newsletters published since the previous release. It might make sense to explicitly add a "ChangeLog" message to important commits, so that the Changelog can be compiled more easily ?
** {{Thumbs up}} The changelog can be easily written by using "git log", searching the issue tracker and by going through the last 6 newsletters published since the previous release. It might make sense to explicitly add a "ChangeLog" message to important commits, so that the Changelog can be compiled more easily ?
** Alternatively, request developers to add major changes also to $FG_SRC/ChangeLog again (last updated in 2001)?
** Alternatively, request developers to add major changes also to $FG_SRC/ChangeLog again (last updated in 2001)?
** for the web-based release announcement, it would be helpful to have screen shots or even youtube videos to demonstrate new features
** for the web-based release announcement, it would be helpful to have screen shots or even youtube videos to demonstrate new features
** it may make sense to also allow artwork contributors to contribute new splash screen images for use in the upcoming release. The screen shot contest should provide plenty of options [http://www.flightgear.org/forums/viewtopic.php?f=28&t=16795].
** it may make sense to also allow artwork contributors to contribute new splash screen images for use in the upcoming release. The screen shot contest should provide plenty of options [http://www.flightgear.org/forums/viewtopic.php?f=28&t=16795].
 
* Shaders:
* Shaders
** {{Thumbs up}} lowering the default shader level to 1 improved compatibility for older/underpowered systems [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg39189.html]
** {{Thumbs up}} lowering the default shader level to 1 improved compatibility for older/underpowered systems [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg39189.html]
** GLSL shaders and effects should be treated like core code, and should be tested on different platforms before being enabled by default (i.e. signed-off by people using NVIDIA, ATI/AMD, Intel) [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg39120.html]
** GLSL shaders and effects should be treated like core code, and should be tested on different platforms before being enabled by default (i.e. signed-off by people using NVIDIA, ATI/AMD, Intel) [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg39120.html]
* New/updated Nasal scripts contributed to the base package should be checked to properly support important features like simulator reset, this also applies to Nasal scripts used by aircraft, Nasal scripts that fail these criteria, end up breaking existing features! [https://code.google.com/p/flightgear-bugs/issues/detail?id=956] (also see [[Release:Aircraft Selection Criteria]])
** modified shaders should be tested with other shader-related features to prevent breakage []
* there were a number of navcache/SQLite related issues reported via the issue tracker and the forum/devel list [https://code.google.com/p/flightgear-bugs/issues/detail?id=894]
* FGData (Base Package):
** 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]
** New/updated Nasal scripts contributed to the base package should be checked to properly support important features like simulator reset, this also applies to Nasal scripts used by aircraft, Nasal scripts that fail these criteria, end up breaking existing features! [https://code.google.com/p/flightgear-bugs/issues/detail?id=956] (also see [[Release:Aircraft Selection Criteria]])
* there were a number of navcache/SQLite related issues reported via the issue tracker and the forum/devel list [https://code.google.com/p/flightgear-bugs/issues/detail?id=894] [http://flightgear.org/forums/viewtopic.php?f=68&p=175690#p175690]
* 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]
* Release Candidates:
* 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]
** 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]
** 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]
** 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]
** 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]
Retrieved from "https://wiki.flightgear.org/Special:MobileDiff/57536"