Release-Management: Difference between revisions
Jump to navigation
Jump to search
(clean-up) |
(Add to category Release) |
||
| Line 1: | Line 1: | ||
[[Category:Release]] | |||
The release management process for the Qt Project needs to be formed by discussions in the community. This means that the community, through consensus, defines how, when and by whom Qt is released. The Nokia release engineering team has some ideas on how this could be done, but will bring those discussions to the mailing lists of the Qt Project. | The release management process for the Qt Project needs to be formed by discussions in the community. This means that the community, through consensus, defines how, when and by whom Qt is released. The Nokia release engineering team has some ideas on how this could be done, but will bring those discussions to the mailing lists of the Qt Project. | ||
Revision as of 13:05, 22 November 2016
The release management process for the Qt Project needs to be formed by discussions in the community. This means that the community, through consensus, defines how, when and by whom Qt is released. The Nokia release engineering team has some ideas on how this could be done, but will bring those discussions to the mailing lists of the Qt Project.
Here are some primer for those discussions.:
- Most important tools for communication
- Mailing lists
- Jira issue tracker
- IRC on Freenode
- Time-based releases provide a more sensible and equal basis for all parties involved
- 6 months release cycles?
- Encourages early and frequent feedback
- Provides easy access to the latest and greatest features
- Shows genuine project activity
- Builds developer confidence
- Facilitates a manageable upgrade path for users
- Releases are stabilized in their minor branches, and final release is tagged
- This means no minor release branches
- CHANGES file is updates as part of individual patches
- Each module has its own CHANGES file