You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Each release goes through the following milestones and stages:
8
+
9
+
## Announcement Preparation
10
+
11
+
A release may be triggered for several reasons.
12
+
- An event or dependency in the development roadmap may require a release.
13
+
- There may be a desire to have a major release included in a major platform release like the next version of Ubuntu.
14
+
- Or it may be that a significant set of features has matured to the point that they are ready for general usage.
15
+
16
+
Whatever the reason, the first step in the determination by the maintainers that a release is needed.
17
+
18
+
The maintainers will create a Github project to track the release.
19
+
The maintainers will schedule a meeting to review outstanding Pull Requests.
20
+
21
+
22
+
## Announcment milestone
23
+
24
+
Next, the maintainers will make a formal announcment on the forum. The announcement will layout the expected timeline for the release and call for final submissions. The announcment should be further communicated through official and unofficial channels like Twitter and Reddit.
25
+
26
+
## Final Feature Submission Stage
27
+
28
+
The purpose of the announcment is to let contributors know that a feature freeze is imminent. Any work in process should be finalized and a Pull Request submitted.
29
+
30
+
At this point, a PR may not be ready to merge and can be marked as _draft_. Creating the PR makes the maintainer community aware of pending changes that the contributor would like to have considered for the release. The maintainers will allow time (typically 1-2 weeks) for Pull Requests to be submitted.
31
+
32
+
The announcment should include a date for the PR Review meeting.
33
+
34
+
The announcment should also announce a splash-screen contest and provide a forum thread for submissions.
35
+
36
+
## PR Review Milestone
37
+
38
+
After the Submission Stage is closed, the maintainers will review all outstanding Pull Requests. For each one, they will determine if the feature is sufficiently mature to include in the release. Specifically they will consider:
39
+
40
+
- How significant is the feature
41
+
- How likely is the feature to negatively impact user workflow
42
+
- How well documented is the new feature
43
+
- How much additional testing and stabilization is likely required
44
+
45
+
Maintainers will strive to include as many mature features as possible while minimizing the time needed to resolve bugs, complete documentation, and stabilize the release.
46
+
47
+
Each PR will be tagged with the current release if it is to be included.
48
+
49
+
Following the PR Review, any new feature Pull Requests will be held for a later version. Contributors should adjust their expectations about code reviews.
50
+
51
+
## PR Merge Phase
52
+
53
+
During this phase, development focus will turn towards merging the remaining tagged outstanding PRs.
54
+
After the PR Merge phase, only bug-fix PRs will be merged.
55
+
56
+
## Release Candidates
57
+
58
+
After all outstanding PRs are merged and all critical bugs are resolved, a Release Candidate (RC) version will be created and a public announcment made. This is a request to the community for intentional and deliberate testing with the goal of uncovering as many bugs as possible.
59
+
60
+
Translation files will be pushed to CrowdIn and a public call for translation assistance should be made.
61
+
62
+
Release notes should be reviewed at this point and any ommisions corrected
63
+
64
+
Numerous release candidates may be produced as critical bugs are addressed.
65
+
66
+
## Final Release
67
+
68
+
- The result of the splash screen contest is announced and the new splash screen is added to the source.
69
+
70
+
- update all versions in a number of source code locations:
71
+
- README.md
72
+
- appveyor.yml
73
+
- CMakeLists.txt
74
+
- src/Tools/offlinedoc/buildqhelp.py
75
+
- src/XDGData/org.freecadweb.FreeCAD.appdata.xml
76
+
- vagrant/Xenial/generate_yaml.sh
77
+
- vagrant/Xenial/bin/launcher
78
+
- vagrant/generate_yaml.sh
79
+
- vagrant/FreeCAD.sh
80
+
81
+
- Prepare a packager's release files and alert the packagers.
Between major releases, bugs are occasionally found and repaired. These fixes may be urgent enough or isolated enough that applying them incrementally to the existing ‘stable’ version is both possible and desirable. A set of such changes may be grouped together and released as a ‘minor’ version.
6
+
7
+
Usually these fixes have already been applied to the development branch. The process of applying them to the previous stable version is called 'backporting'
8
+
9
+
## Stages
10
+
11
+
Each minor release goes through the following stages:
12
+
13
+
## Creation of Release Milestone
14
+
15
+
The need for a minor release is triggered by a PR or commit which is deemed worth backporting to the stable version. The consideration is based on a couple factors
16
+
17
+
- Does the bug result in the loss of data under normal circumstances?
18
+
- Does the bug expose user data or present the possibility of user data being
19
+
exposed?
20
+
- Does the bug create a significant inconvenience for the user?
21
+
22
+
When a PR or commit is found worth backporting, a maintainer will create a new issue. The issue should have suitable title like [BACKPORT REQUEST] <somedescription>
23
+
24
+
The issue should link to the PR in question.
25
+
26
+
The issue should be labeled with a Milestone label for the next minor release. If the milestone label doesn't exist, the maintainer will create it.
27
+
28
+
## Create a backport PR
29
+
30
+
A maintainer will create a new PR targeting the stable branch. The relevant commits can be cherry-picked and added to the new PR.
31
+
32
+
The backport PR will go through the same process as any other PR.
33
+
34
+
## Creating the Minor version release
35
+
36
+
Minor bugs may be gathered together for a period of days or weeks to batch them together. A significant bug or one that risks user data may require an expedited release.
37
+
38
+
When the determination is made to proceed with the release, the following things happen"
Copy file name to clipboardExpand all lines: technical/ReleaseProcess.md
+6-80Lines changed: 6 additions & 80 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -8,87 +8,13 @@ This page describes a high-level overview of the release planning and management
8
8
9
9
We recognize signficant wisdom in the philosophy to ["Release Early and Release Often"](https://en.wikipedia.org/wiki/Release_early,_release_often). However, releases can require significant coordinated work within the community. FreeCAD aspires to produce a major release every 3-6 months. In order to meet this goal, we will work to make releases more predicatable and automated.
10
10
11
-
## Stages
11
+
## Major and Minor Releases
12
12
13
-
Each release goes through the following milestones and stages:
13
+
A major release introduces new features and introduces key improvements. Major releases may also introduce breaking changes that invalidate documentation or change existing APIs. They may also deprecate older functionality.
14
14
15
-
### Announcement Preparation
15
+
Between major releases, bugs are occasionally found and repaired. These fixes may be urgent enough or isolated enough that applying them incrementally to the existing 'stable' version is both possible and desirable. A set of such changes may be grouped together and released as a 'minor' version.
16
16
17
-
A release may be triggered for several reasons.
18
-
- An event or dependency in the development roadmap may require a release.
19
-
- There may be a desire to have a major release included in a major platform release like the next version of Ubuntu.
20
-
- Or it may be that a significant set of features has matured to the point that they are ready for general usage.
17
+
Major and minor releases have slightly different processes.
21
18
22
-
Whatever the reason, the first step in the determination by the maintainers that a release is needed.
23
-
24
-
The maintainers will create a Github project to track the release.
25
-
The maintainers will schedule a meeting to review outstanding Pull Requests.
26
-
27
-
28
-
### Announcment milestone
29
-
30
-
Next, the maintainers will make a formal announcment on the forum. The announcement will layout the expected timeline for the release and call for final submissions. The announcment should be further communicated through official and unofficial channels like Twitter and Reddit.
31
-
32
-
### Final Feature Submission Stage
33
-
34
-
The purpose of the announcment is to let contributors know that a feature freeze is imminent. Any work in process should be finalized and a Pull Request submitted.
35
-
36
-
At this point, a PR may not be ready to merge and can be marked as _draft_. Creating the PR makes the maintainer community aware of pending changes that the contributor would like to have considered for the release. The maintainers will allow time (typically 1-2 weeks) for Pull Requests to be submitted.
37
-
38
-
The announcment should include a date for the PR Review meeting.
39
-
40
-
The announcment should also announce a splash-screen contest and provide a forum thread for submissions.
41
-
42
-
### PR Review Milestone
43
-
44
-
After the Submission Stage is closed, the maintainers will review all outstanding Pull Requests. For each one, they will determine if the feature is sufficiently mature to include in the release. Specifically they will consider:
45
-
46
-
- How significant is the feature
47
-
- How likely is the feature to negatively impact user workflow
48
-
- How well documented is the new feature
49
-
- How much additional testing and stabilization is likely required
50
-
51
-
Maintainers will strive to include as many mature features as possible while minimizing the time needed to resolve bugs, complete documentation, and stabilize the release.
52
-
53
-
Each PR will be tagged with the current release if it is to be included.
54
-
55
-
Following the PR Review, any new feature Pull Requests will be held for a later version. Contributors should adjust their expectations about code reviews.
56
-
57
-
### PR Merge Phase
58
-
59
-
During this phase, development focus will turn towards merging the remaining tagged outstanding PRs.
60
-
After the PR Merge phase, only bug-fix PRs will be merged.
61
-
62
-
### Release Candidates
63
-
64
-
After all outstanding PRs are merged and all critical bugs are resolved, a Release Candidate (RC) version will be created and a public announcment made. This is a request to the community for intentional and deliberate testing with the goal of uncovering as many bugs as possible.
65
-
66
-
Translation files will be pushed to CrowdIn and a public call for translation assistance should be made.
67
-
68
-
Release notes should be reviewed at this point and any ommisions corrected
69
-
70
-
Numerous release candidates may be produced as critical bugs are addressed.
71
-
72
-
### Final Release
73
-
74
-
- The result of the splash screen contest is announced and the new splash screen is added to the source.
75
-
76
-
- update all versions in a number of source code locations:
77
-
- README.md
78
-
- appveyor.yml
79
-
- CMakeLists.txt
80
-
- src/Tools/offlinedoc/buildqhelp.py
81
-
- src/XDGData/org.freecadweb.FreeCAD.appdata.xml
82
-
- vagrant/Xenial/generate_yaml.sh
83
-
- vagrant/Xenial/bin/launcher
84
-
- vagrant/generate_yaml.sh
85
-
- vagrant/FreeCAD.sh
86
-
87
-
- Prepare a packager's release files and alert the packagers.
0 commit comments