Release-Management: Difference between revisions

From Qt Wiki
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
** <span class="caps">IRC</span> on Freenode
** 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
* <span class="caps">CHANGES</span> file is updates as part of individual patches
* CHANGES file is updates as part of individual patches
* Each module has its own <span class="caps">CHANGES</span> file
* Each module has its own CHANGES file
 
===Categories:===
 
* [[:Category:Developing Qt|Developing_Qt]]

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