Release plan: Difference between revisions

Jump to navigation Jump to search
2,117 bytes added ,  18 December 2015
http://sourceforge.net/p/flightgear/mailman/message/34701971/ (with some "wikification" and typo corrections)
(Some updates, mostly importantly add note about future changes to release process)
(http://sourceforge.net/p/flightgear/mailman/message/34701971/ (with some "wikification" and typo corrections))
Line 1: Line 1:
{{Note|As of Decemeber 2015, the release plan is in the process of being changed so that the description below will no longer be accurate. See also [[Release plan/Lessons learned#3.60|Release plan/Lessons learned § 3.60]].}}
{{Note|1=As of Decemeber 2015, the release plan is in the process of being changed so that the description below will no longer be accurate:
 
{{FGCquote
|1= Hi Everybody,
 
Today, December 17th would be the day to announce the feature freeze for
3.8 if we were following the usual release schedule.
 
A while ago I proposed a change in that schedule and I have spent some time
on preparing the scripts for an automated release process since then. I
think I have pretty much everything ready to go for automated releases and
now I'd like to give it a first try for the 3.8 release next year.
 
For the first execution, I'd like to trigger the scripts manually on my
local machine instead of Jenkins to have some better control of it. If it
works out as expected, I'll put this onto our Jenkins server afterwards to
be executed automatically for the release following after 3.8.
 
For now, I propose the following and would do so if nobody objects:
* There is no feature freeze for the next (3.8) and the following releases
* On Jan., 17th I trigger my first script to create release/3.8 branches with version 3.8.1 (!)
* Immediately after that I let Jenkins create the binaries for 3.8.1 and we have our first release
* Patches going into the release/3.8 branch automatically trigger a new build with a previous increase of the micro version number (3.8.2, 3.8.3,..) and we immediately have a bugfix release
* On 'next', version numbers go to 3.9.0
* Nightly builds are created from next after every push in that branch
 
After a to-be-defined period (my proposal: 3 month) we start over:
* Create a release/3.9 branch with version 3.9.1
* etc. etc.
 
Note: there will be no odd-even version number scheme (odd equals unstable,
even equals stable). Instead, x.x.0 is unstable, nightly from next and
x.x.n where n >= 1 is a stable release.
 
If everything works as expected, we have a major release every
to-be-defined months, a bugfix release after every push to the release
branch and a nightly build after every push to 'next'.
 
I hope this sounds reasonable and keeps everybody happy.
 
Feedback welcome.
 
Torsten
|2= {{cite web
  | url    = http://sourceforge.net/p/flightgear/mailman/message/34701971/
  | title  = <nowiki>[Flightgear-devel] Relesae 3.8</nowiki>
  | author = <nowiki>Torsten Dreyer</nowiki>
  | date  = Dec 17th, 2015
  }}
}}
}}


{{GitStatus}}
{{GitStatus}}

Navigation menu