Release plan: Difference between revisions

Jump to navigation Jump to search
Line 112: Line 112:


=== Open Items, Questions ===
=== Open Items, Questions ===
* <s>Can Jenkins create binaries (RC) from the release branch?</s> Binaries: yes, installers: semiautomatic (Curt &amp; Tat)
* Automate the creation of Windows and Mac installers
* <s>If not, how often will we create RC?</s> Weekly
* Automate the creation of FGDATA distribution
* Surely the beta testing rôle could/should be undertaken by selected members the community - selected based on their ability to write clearly and to write usefully. (computer specifications, errors from the console, and other pieces of useful objective information - no subjective rot such as "it doesn't work")
 
** Surely not! The more people beta-test our release candidates, the better.
=== 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.

Navigation menu