Difference between revisions of "Release cycle"
(→Preview snapshots) |
(→Release Cycle) |
||
Line 16: | Line 16: | ||
= Release Cycle = | = Release Cycle = | ||
− | 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 ;-) ). | + | 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 ;-) ). |
[[File:Freeplane Release model.png|Freeplane Release model|800px]] | [[File:Freeplane Release model.png|Freeplane Release model|800px]] | ||
− | As shown above, the release cycle of Freeplane consists of | + | As shown above, the release cycle of Freeplane consists of 3 phases: |
− | + | ==Alpha== | |
− | + | 3-6 months of "wild" development on trunk branch<br> | |
− | ; Beta | + | * Branch the next release e.g. Branch_1.0.x - developers can continue to bring in new features on MAIN/HEAD/trunk. |
+ | * Snapshot versions can be published on page http://freeplane.sourceforge.net/preview/ | ||
+ | |||
+ | ⇒ The phase ends when release branch is created from the trunk<br> | ||
+ | |||
+ | ==Beta== | ||
+ | 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.<br> | ||
⇒ Create RC1 (Release Candidate) - call for translations, 3rd party plugins and packaging. | ⇒ Create RC1 (Release Candidate) - call for translations, 3rd party plugins and packaging. | ||
− | ; Release Candidate (RC) | + | ; Release Candidate (RC) |
− | + | 1 month of integration of translations + critical bug fixing | |
− | + | * Beta and RC Distributions can be published on page https://sourceforge.net/projects/freeplane/files/freeplane%20beta/ | |
− | + | * They appears on page http://freeplane.sourceforge.net/testversion/ 4-7 days earlier. | |
+ | |||
+ | ⇒ The phase ends when stable release is created, e.g. 1.1.0. | ||
+ | |||
+ | ==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> | ||
+ | * The stable versions can be published on page https://sourceforge.net/projects/freeplane/files/freeplane%20stable/<br> | ||
+ | * They appears on page http://freeplane.sourceforge.net/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. | 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. |
Revision as of 08:55, 1 August 2010
Freeplane will follow a testing,tracking and release policy as described below.
Contents
Preview snapshots
Preview versions can be uploaded to a preview area.
Test releases
Test releases will be uploaded first to a testing area and later will be released on sourceforge after one or more tester confirms that no major bugs have been introduced in the test version.
Bug handling
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.
Release Cycle
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 ;-) ).
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.
- Snapshot versions can be published on page http://freeplane.sourceforge.net/preview/
⇒ The phase ends when release branch is created from the trunk
Beta
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
- Beta and RC Distributions can be published on page https://sourceforge.net/projects/freeplane/files/freeplane%20beta/
- They appears on page http://freeplane.sourceforge.net/testversion/ 4-7 days earlier.
⇒ The phase ends when stable release is created, e.g. 1.1.0.
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 appears on page http://freeplane.sourceforge.net/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.