Difference between revisions of "Release cycle"

From Freeplane - free mind mapping and knowledge management software
m (Text replacement - "http://www.freeplane.org" to "https://www.freeplane.org")
 
(15 intermediate revisions by 4 users not shown)
Line 1: Line 1:
Freeplane will follow a testing,tracking and release policy as described below.
+
Freeplane's release cycle is time boxed at 6-9 months, and meant to allow for 1-2 stable releases per year (but much more unstable releases ;-) ).
  
== Test releases ==
+
[[File:Freeplane Release model.png|Freeplane Release model|800px]]
  
Test releases will be uploaded first to a [http://freeplane.sourceforge.net/testversion/ testing area] and later will be released on [http://sourceforge.net/projects/freeplane/files/ sourceforge] after one or more tester confirms that no major bugs have been introduced in the test version.
+
As shown above, the release cycle of Freeplane consists of 3 phases:
  
== Bug handling ==
+
==Alpha==
 +
3-6 months of "wild" development on trunk branch<br>
 +
* Branch the next release e.g. Branch_1.0.x - developers can continue to bring in new features on MAIN/HEAD/trunk.
 +
&rArr; The phase ends when release branch is created from the trunk<br>
  
FreePlane uses Mantis BT as bug tracker (https://sourceforge.net/apps/mantisbt/freeplane). Bugs should be set to resolved once the developer has fixed it and checked-in the changes in the version tool. The bug should be kept open to allow testers to alert the developers of a recurrence. The bugs can be closed in RC phase.
+
=== Preview snapshots ===
 +
Preview versions can be uploaded to a [https://www.freeplane.org/preview/ preview area].
  
== Current and next release stages ==
+
Before downloading and trying the preview versions read and accept these warnings:
 +
* They are not intended for any productive use.
 +
* There is no support for them.
 +
* Data format and properties may be changed for preview versions without any notice.
 +
* Files and user properties saved by the preview versions may be not properly handled by any previous or following program versions.
  
* '''Beta''' : Freeplane is currently in beta stage.  
+
==Unstable==
 
+
3 months of bug fixing releases on the release branch
* '''Release candidate''': Freeplane will move to release candidate stage when no bugs have been reported for 2 weeks. Perhaps we should have a "bug crush" period. Each RC should last no longer than a month. Hopefully few bug reports will be coming in at this point.  
+
===Beta===
 
+
2 months of bug fixing releases on Branch_1.0.x - that would be Beta releases.<br>
* '''Stable''': Freeplane should aim to be stable after no more than three RCs as long as no major bugs are reported in the release. We should seek users feedbacks for quality assurance.
+
&rArr; Create RC1 (Release Candidate) - call for translations, 3rd party plugins and packaging.
 
+
===Release Candidate (RC)===
= Release Cycle =
+
1 month of integration of translations + critical bug fixing
 +
&rArr; The phase ends when stable release is created, e.g. 1.1.0.
 +
=== Test releases ===
 +
Test releases will be uploaded first to a testing area https://www.freeplane.org/testversion/  and can be released on https://sourceforge.net/projects/freeplane/files/freeplane%20beta/ 4-7 days later after one or more tester confirms that no major bugs have been introduced in the test version.
  
Freeplane's release cycle is time boxed at 6 months, and meant to allow for 2 stable releases per year (but much more unstable releases ;-) ).
 
  
[[File:Freeplane Release model.png|Freeplane Release model|800px]]
+
==Stable==
 +
final packaging can only happen after final release so we can only make sure that it all happen in a limited timeframe).<br>
 +
new bug fixing / stable releases can be done as required, called 1.1.1, 1.1.2...<br>
  
As shown above, the release cycle of Freeplane consists of 4 phases:
+
The stable versions can be published on page https://sourceforge.net/projects/freeplane/files/freeplane%20stable/.<br>
 +
They appear on page https://www.freeplane.org/testversion/ 4-7 days earlier.
  
; Alpha : 3 months of "wild" development on MAIN/HEAD/trunk (CVS resp. SVN talk)
 
&rArr; Branch the next release e.g. Branch_1.0.x - developers can continue to bring in new features on MAIN/HEAD/trunk.
 
; Beta : 2 months of bug fixing releases on Branch_1.0.x - that would be Beta releases.
 
&rArr; Create RC1 (Release Candidate) - call for translations, 3rd party plugins and packaging.
 
; Release Candidate (RC) : 1 month of integration of translations + critical bug fixing (3rd party plugins and packaging as well, but final packaging can only happen after final release so we can only make sure that it all happen in a limited timeframe).
 
&rArr; Create Final release, e.g. 1.1.0.
 
; Stable : new bug fixing / stable releases can be done as required, called 1.1.1, 1.1.2...
 
&rArr; Restart the cycle e.g. for 1.2.x
 
  
 
Another way to show the approach is the following 3 pictures. The blue line turns clockwise while we progress through a release cycle; what is right of the line (in Green) is allowed to be done, what is left of the line (in Red) isn't.
 
Another way to show the approach is the following 3 pictures. The blue line turns clockwise while we progress through a release cycle; what is right of the line (in Green) is allowed to be done, what is left of the line (in Red) isn't.
Line 39: Line 44:
  
 
[[File:Freeplane Release Cycle Alpha.png|Alpha phase|350px]][[File:Freeplane Release Cycle Beta.png|Beta phase|350px]][[File:Freeplane Release Cycle RC.png|Release Candidate phase|350px]]
 
[[File:Freeplane Release Cycle Alpha.png|Alpha phase|350px]][[File:Freeplane Release Cycle Beta.png|Beta phase|350px]][[File:Freeplane Release Cycle RC.png|Release Candidate phase|350px]]
 +
 +
== Bug handling ==
 +
 +
Freeplane uses the Sourceforge/Allura ticket system as bug tracker (https://sourceforge.net/p/freeplane/bugs/). Bugs should be set to resolved once the developer has fixed it and checked-in the changes in the version tool. The bug should be kept open to allow testers to alert the developers of a recurrence. The bugs can be closed in RC phase.
 +
 +
[[Category:Coding]]

Latest revision as of 19:17, 18 November 2018

Freeplane's release cycle is time boxed at 6-9 months, and meant to allow for 1-2 stable releases per year (but much more unstable releases ;-) ).

Freeplane Release model

As shown above, the release cycle of Freeplane consists of 3 phases:

Alpha

3-6 months of "wild" development on trunk branch

  • Branch the next release e.g. Branch_1.0.x - developers can continue to bring in new features on MAIN/HEAD/trunk.

⇒ The phase ends when release branch is created from the trunk

Preview snapshots

Preview versions can be uploaded to a preview area.

Before downloading and trying the preview versions read and accept these warnings:

  • They are not intended for any productive use.
  • There is no support for them.
  • Data format and properties may be changed for preview versions without any notice.
  • Files and user properties saved by the preview versions may be not properly handled by any previous or following program versions.

Unstable

3 months of bug fixing releases on the release branch

Beta

2 months of bug fixing releases on Branch_1.0.x - that would be Beta releases.
⇒ Create RC1 (Release Candidate) - call for translations, 3rd party plugins and packaging.

Release Candidate (RC)

1 month of integration of translations + critical bug fixing ⇒ The phase ends when stable release is created, e.g. 1.1.0.

Test releases

Test releases will be uploaded first to a testing area https://www.freeplane.org/testversion/ and can be released on https://sourceforge.net/projects/freeplane/files/freeplane%20beta/ 4-7 days later after one or more tester confirms that no major bugs have been introduced in the test version.


Stable

final packaging can only happen after final release so we can only make sure that it all happen in a limited timeframe).
new bug fixing / stable releases can be done as required, called 1.1.1, 1.1.2...

The stable versions can be published on page https://sourceforge.net/projects/freeplane/files/freeplane%20stable/.
They appear on page https://www.freeplane.org/testversion/ 4-7 days earlier.


Another way to show the approach is the following 3 pictures. The blue line turns clockwise while we progress through a release cycle; what is right of the line (in Green) is allowed to be done, what is left of the line (in Red) isn't. This means that everything is allowed during Alpha phase, that in Beta we should avoid major rewrite unless it's needed to fix a critical bug, and, as we come to RC, almost nothing is allowed but to fix critical bugs.

Side note
the line progresses continuously, it's not a sudden jump, e.g. during beta, we implement always less new things, even if they're easy to do, and fix always more bug, thus regularly stabilizing the code basis.

Alpha phaseBeta phaseRelease Candidate phase

Bug handling

Freeplane uses the Sourceforge/Allura ticket system as bug tracker (https://sourceforge.net/p/freeplane/bugs/). Bugs should be set to resolved once the developer has fixed it and checked-in the changes in the version tool. The bug should be kept open to allow testers to alert the developers of a recurrence. The bugs can be closed in RC phase.