Release plan: Difference between revisions

1,069 bytes removed ,  7 January 2016
Comment out a lot of stuff
(→‎Version numbers: Finish section)
(Comment out a lot of stuff)
Line 56: Line 56:


[[File:ReleasePlan.jpg|thumb|250px|The original release plan.]]
[[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.
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.
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.
Line 96: Line 96:
{{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.}}
{{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 ==
== Detailed time schedule and checklist ==
# '''Dec/Jun 17th:''' Development stream is declared "frozen" or "yellow"
# '''Dec/Jun 17th:''' Development stream is declared "frozen" or "yellow"
Line 112: Line 113:
##:for the tags (all repos): <code>git push origin version/3.0.0</code>
##: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
# '''Jan/Jul 17th:''' Create new release branch, assign new version number to dev-stream, re-open streams
<!-- We don't really need this step...
 
 
-- We don't really need this step... --
##Declare the streams "closed" or "red"
##Declare the streams "closed" or "red"
##:Send a mail to the flightgear-devel mail-list, asking not to commit/push anything
##:Send a mail to the flightgear-devel mail-list, asking not to commit/push anything
##:Post an update to the forum topic
##:Post an update to the forum topic
##:Change the content of wiki template at [[Template:GitStatus]] to <code><nowiki>{{GitStatus:closed}}</nowiki></code>
##: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):
##Pull current Git, create the release branches (for sg/fg/fgrun/fgdata):
##:<code>git pull</code>
##:<code>git pull</code>
Line 155: Line 159:
##:<code>git push origin master</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.
##[[: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 [http://sourceforge.net/p/flightgear/fgrun/ci/next/tree/version version] file
 
== Definition of repository states ==
== Definition of repository states ==
{| class="wikitable"
{| class="wikitable"
Line 194: Line 194:
'''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.
'''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 ==
== Bug tracking ==
The [http://sourceforge.net/p/flightgear/codetickets/ bugtracker] will be our primary source for the bug fixing period. Bugs reported on the mailing list or forum 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 easier. Bug reports that can't be confirmed or need more input from the reporter 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 downgraded, if no progress has been made over a certain amount of time. This is to prevent 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.
The [http://sourceforge.net/p/flightgear/codetickets/ bugtracker] is the primary source of bug reports. Unlike the forum or mailing list, bugs reported there will be tracked, making it easier for developers to. When reporting bugs, it is best to provide as muh information as possible to more easily find the bug.
 
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 [http://code.google.com/p/flightgear-bugs/issues/list?can=1&q=label%3AMilestone-2.12.0 the list of fixed bugs].


<!--
=== Tasks and owners ===
=== Tasks and owners ===


Line 267: Line 267:
== Open items, questions ==
== 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=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg39205.html |title=<nowiki>Re: [Flightgear-devel] Release candidates</nowiki> |author=Torsten Dreyer |date=29 January 2013}}</ref>
* 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=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg39205.html |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>http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40650.html</ref> (see [[FlightGear Build Server]])
* Automate the creation of fgdata distribution
* 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=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg39109.html |title=<nowiki>Re: [Flightgear-devel] [Jsbsim-devel] JSBSim Synch with FlightGear</nowiki> |author=Torsten Dreyer |date=13 January 2013}}</ref><ref>{{Cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40201.html |title=<nowiki>Re: [Flightgear-devel] JSBSim Synch with FlightGear</nowiki> |author=Anders Gidenstam |date=11 June 2013}}</ref><ref>
* 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=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg39109.html |title=<nowiki>Re: [Flightgear-devel] [Jsbsim-devel] JSBSim Synch with FlightGear</nowiki> |author=Torsten Dreyer |date=13 January 2013}}</ref><ref>{{Cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40201.html |title=<nowiki>Re: [Flightgear-devel] JSBSim Synch with FlightGear</nowiki> |author=Anders Gidenstam |date=11 June 2013}}</ref><ref>
Line 274: Line 273:
</ref>
</ref>


-->
== Lessons learned ==
== 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.  
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}}
<!-- {{Appendix}} -->


[[Category:Core developer documentation]]
[[Category:Core developer documentation]]
[[Category:FlightGear]]
[[Category:FlightGear]]