Release-Management: Difference between revisions
Jump to navigation
Jump to search
AutoSpider (talk | contribs) (Add "cleanup" tag) |
(IRC channels have moved to Libera.Chat) |
||
| (2 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
[[Category:Release]] | |||
[[Category: | |||
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 12: | Line 7: | ||
** Mailing lists | ** Mailing lists | ||
** Jira issue tracker | ** Jira issue tracker | ||
** IRC on | ** IRC on Libera.Chat | ||
* 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? | ||
Latest revision as of 16:01, 5 June 2021
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 Libera.Chat
- 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