Release plan: Difference between revisions

Jump to navigation Jump to search
→‎2.10: Add a suggestion for source snapshots pre-release
(Lessons learned: remove placeholder)
(→‎2.10: Add a suggestion for source snapshots pre-release)
Line 200: Line 200:
* 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]
* 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]
** When releasing RC's do not limit them to Win/Mac binaries, but also create source snapshots so that distros can already work on the next package versions.
* 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]])
* 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]])
* A normal Linux user has practically no change 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]
* 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.
* 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.
* it may make sense to also allow art work 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 art work 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].
111

edits

Navigation menu