111
edits
(Lessons learned: remove placeholder) |
Papillon81 (talk | contribs) (→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 | * 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]. |
edits