Jump to: navigation, search

Release plan

1,069 bytes removed, 17:25, 7 January 2016
Comment out a lot of stuff
[[File:ReleasePlan.jpg|thumb|250px|The original release plan.]]
FlightGear has had two release plans over [[FlightGear History|history]]. The original release plan was developed by Mathias Fröhlich, Martin Spott, Thorsten Brehm and Torsten Dreyer during LinuxTag 2011. The current plan was proposed by Torsten Dreyer after the 3.6 release was [[FlightGear Newsletter November 2015#FlightGear v3.6 canceled|cancelled]].
To suggest improvements and/or changes to the release plan, it is recommended to get in touch via the [[mailing list]]. Improvements can be based on the [[Release plan/Lessons learned|lessons learned]] from previous releases.
{{note|In general, release are referred to by their first two digits (e.g., 3.4). However, when filing a bug report or debugging problems, it is a good idea to give the full release number.}}
== Detailed time schedule and checklist ==
# '''Dec/Jun 17th:''' Development stream is declared "frozen" or "yellow"
##:for the tags (all repos): <code>git push origin version/3.0.0</code>
# '''Jan/Jul 17th:''' Create new release branch, assign new version number to dev-stream, re-open streams
<! -- We don't really need this step...--
##Declare the streams "closed" or "red"
##:Send a mail to the flightgear-devel mail-list, asking not to commit/push anything
##:Post an update to the forum topic
##:Change the content of wiki template at [[Template:GitStatus]] to <code><nowiki>{{GitStatus:closed}}</nowiki></code>
##Pull current Git, create the release branches (for sg/fg/fgrun/fgdata):
##:<code>git pull</code>
##:<code>git push origin master</code>
##[[:Category:FlightGear Core developers|Core developers]] and other contributors should be invited to add their release related experiences (i.e. suggestions for improvements) to the wiki to help update and improve the release plan (i.e. this page) accordingly.
== Version files ==
; FGData: {{fgdata file|version}}
; SimGear: {{simgear file|version}}
; FlightGear: {{flightgear file|version}}
== To bump up the version number ==* fgdata** edit the {{fgdata file|version|t=version}} file* SimGear** edit the {{simgear file|version|t=version}} file* FlightGear** edit the {{flightgear file|version|t=version}} file* FGRun** edit the [ version] file<!--
== Definition of repository states ==
{| class="wikitable"
'''DO NOT''' merge next into release/2.8.0 or vice versa. Most likely, there will be commits that are not welcome in or even break the other branch.
== Bug tracking ==
The [ bugtracker] will be our is the primary source for the of bug fixing periodreports. Bugs reported on Unlike the forum or mailing list or forum , bugs reported there will not be tracked! Reporters shall be requested to file a bug report at the bugtracker. Bugs shall be assigned a priority and a keyword to make the assignment to a developer , making it easier. Bug reports that can't be confirmed or need more input from the reporter for developers to get fixed will be assigned a new state "stalled" and only processed after more information has been provided. Bugs assigned a high priority will be downgradedWhen reporting bugs, if no progress has been made over a certain amount of time. This it is best to prevent provide as muh information as possible to more easily find the release from being blocked by a bug that no developer is able (or willing) to fix. The only exception is "does not compile for one of the major platforms", which certainly is a release-blocker. Bugs that were present in the latest stable release, and now considered "fixed", should be assigned a milestone label, corresponding with the upcoming stable release number. By doing so, they'll end up in [ the list of fixed bugs].
=== Tasks and owners ===
== Open items, questions ==
* Automate and/or document the creation of RC's: "We need to get this automated some day. Or at least documented...(another one from "famous last words": if you have to do it more than once, automate it. If you can't automate it, document it."<ref>{{Cite web |url= |title=<nowiki>Re: [Flightgear-devel] Release candidates</nowiki> |author=Torsten Dreyer |date=29 January 2013}}</ref>
* <del>Automate the creation of Windows and Mac installers</del> {{Done}} <ref></ref> (see [[FlightGear Build Server]])
* Automate the creation of fgdata distribution
* Possibly try to find a way to automate testing of updated jsbsim code, so that the chance for breakage is reduced by running scripted tests <ref>{{Cite web |url= |title=<nowiki>Re: [Flightgear-devel] [Jsbsim-devel] JSBSim Synch with FlightGear</nowiki> |author=Torsten Dreyer |date=13 January 2013}}</ref><ref>{{Cite web |url= |title=<nowiki>Re: [Flightgear-devel] JSBSim Synch with FlightGear</nowiki> |author=Anders Gidenstam |date=11 June 2013}}</ref><ref>
== Lessons learned ==
See [[Release plan/Lessons learned]] for a list of things that turned out well and should be kept for the next release as well as thing that didn't turn out so well and should be changed for future releases. Ideally, the release plan should be updated and augmented so that the lessons learned are incorporated accordingly.
<!-- {{Appendix}}-->
[[Category:Core developer documentation]]

Navigation menu