Release-Management

This article may require cleanup to meet the Qt Wiki's quality standards. Reason: Auto-imported from ExpressionEngine. Please improve this article if you can. Remove the {{cleanup}} tag and add this page to Updated pages list after it's clean.

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