381
edits
Line 112: | Line 112: | ||
=== Open Items, Questions === | === Open Items, Questions === | ||
* | * Automate the creation of Windows and Mac installers | ||
* | * Automate the creation of FGDATA distribution | ||
* | |||
** | === Lessons Learned === | ||
This is a list of lessons learned from the previous release, things that turned out well and should be kept for the next release as well as thing thad didn't turn out so well and should be changed for future releases. | |||
* Good: feature freeze in general | |||
*: helped a lot during release management. Kept the commit traffic low and thus helped identifying those commits required to pick into the release. | |||
* Not so good: feature freeze for aircraft | |||
*: Technically, a feature freeze for aircraft is not necessary as long as this aircraft is not part of the base distribution and no common parts are affected. If it's guaranteed that the changes remain in FGDATA/Aircraft/MyAircraft and no other files are touched, these updates should be OK up to shortly before the release. | |||
* Not so good: switching to a new version of supporting libraries like OSG. | |||
*: The move to OSG 3.x introduced some major issues. If at all possible, switch to a new library early in the development cycle. | |||
* Not so good: manual creation of release candidates and the release binaries | |||
*: It's preferable to have equal numbers for release candidates for all O/S and probably a git-tag for each candidate. |