The Quarterly Release Pact is an informal developer agreement to aim for shared, scheduled software release dates.

We agree to release at least four times a year: January, April, July and October the 15th.

To participate you just need to do a release. There is no need to register in advance or ask for permission to participate.

A release is an important step in the development and life of software. Users look forward to updates and improvements, but they mean additional work for developers. It is often very hard to decide if and when to release, so developers tend to wait and postpone. There do not seem to be any objective, measurable reasons that could lead to a decision. Therefore we have decided to use time as a basis.

 

Why should you schedule (at least) four releases per year?

  • Releases punctuate the story of a software life cycle, making it easier for users to follow than through git commit logs
  • Releases get packaged: if your software does something well enough, give it a version number for packagers to use
  • Healthy, active community: a productive peer group of developers who release is good motivation to publish something yourself
  • Social momentum / peer pressure: other people are going to release, so will I
  • Announcements get software in the public eye: opportunity for new users, collaborators, feedback and reflection
  • Swarm marketing: a small release does not have much impact but a group software release demands more attention
  • Communicates trust: people see that the software is in development and cared for and a community exists

 

Minimum Viable Release:

"Fixed typo in documentation" should be enough. Especially for software that has huge release intervals, like a year or longer, there is public uncertainty if a project is just "working as intended" or dead. A minor release with minimal changes is still a signal to the public that the software is not forgotten. There is always something to do: Non-Code accomplishments like writing documentation and user manuals are also a (very good) reason to release.

 

Where can you announce a release?

 

Miscellaneous

  • How to give version numbers: Semantic Versioning
  • Provide release notes: in the form of a CHANGELOG or NEWS file, also as a git tag message for feed syndication
  • Provide a tarball for packaging: a real hosted release as tarball and/or GitHub/GitLab release that results in a tarball
  • Distributions want a stable set of files for packaging. A git tag alone is not stable. Builds are also often isolated from a network
  • Check that your software and information (like README, .desktop file, your own website, etc.) is up to date. Get inspiration: Open-source project release checklist
  • "Why must you document your project? - Various templates & tips on writing high-quality documentation that people want to read.": The Documentation Compendium
  • Does your software still create (dot-)files directly in the homedir? Start supporting the XDG Base Directory Specification

 

Historical links