Release-Management: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
No edit summary |
||
| Line 1: | Line 1: | ||
=Qt Release Management= | [[Category:Developing_Qt]] | ||
= Qt Release Management = | |||
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. | ||
| Line 8: | Line 10: | ||
** Mailing lists | ** Mailing lists | ||
** Jira issue tracker | ** Jira issue tracker | ||
** | ** IRC on Freenode | ||
* Time-based releases provide a more sensible and equal basis for all parties involved | * Time-based releases provide a more sensible and equal basis for all parties involved | ||
** 6 months release cycles? | ** 6 months release cycles? | ||
| Line 18: | Line 20: | ||
* Releases are stabilized in their minor branches, and final release is tagged | * Releases are stabilized in their minor branches, and final release is tagged | ||
** This means no minor release branches | ** This means no minor release branches | ||
* | * CHANGES file is updates as part of individual patches | ||
* Each module has its own | * Each module has its own CHANGES file | ||
Revision as of 10:36, 24 February 2015
Qt Release Management
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