Release plan: Difference between revisions

==== 2.10 ====

** 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]])

** {{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?

** 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].

** {{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]

** Language files should be synced between English and other languages, so translators can work on them before the release ;-)

** 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]])

** 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]

** For RC's it might make sense to distribute binaries with debugging symbols included, so that people can more easily provide useful bug reports, or even backtraces.

** Also, many end users still prefer using the forum for making bug reports and don't use the issue tracker - it might help to add a link (button) to the issue tracker to the about dialog or maybe even directly to the help menu ("Report an issue") (same for wiki/troubleshooting/faq ?)

* A normal Linux user has practically no chance to get last stable on his box running if it isn't in his distro - a normal Windows user gets everything nice and streamlined. [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38817.html]

* According to the issue tracker there were 3-5 different contributors who provided C++ patches that didn't end up reviewed/merged, which caused some irritation.

==== 2.8 ====