The release pact is an informal agreement to aim for shared, scheduled
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?
Developer side:
* Incentive to release something. Releases are better than git
progress. They get packaged, they indicate a (relatively) good state of
the program.
* Momentum/Peer Pressure: Other people are going to release, so will I.
* Healthy, Active Community: Being in a developer group that you see
working (by their releases) is a good motivation to do something
yourself.
User side:
* Announcements: Keep the software in the public eye
* Trust. People see that the software is in development and is cared
for.
* The "last updated" date should never be more than 4 months away and
always the current year.
* Swarm Marketing: A small release does not have much impact and won't
get featured often by news sites. A whole group of software releases
demands more attention. At the moment we simply release on the same
date, but in the future this could grow closer together. As in: joined
press statements etc.
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?
* Send a mail to linux-audio-announce@xxxxxxxxxxxxxxxxxxxx .No
registration needed for posting, the list is moderated.
* Also send a mail to linux-audio-user@xxxxxxxxxxxxxxxxxxxx and
linux-audio-dev@xxxxxxxxxxxxxxxxxxxx . Cross-Posting releases is
accepted. These two lists need registration though.
* Submit your release, or the whole software to https://libreav.org
* Post to https://linuxmusicians.com/viewforum.php?f=24
* Submit a new link or text post to https://old.reddit.com/r/linuxaudio/
* Add or update your entry at
https://gitlab.com/nodiscc/awesome-linuxaudio (see
https://gitlab.com/nodiscc/awesome-linuxaudio/-/blob/master/CONTRIBUTING.md
)
* Add or update your software to Wikipedia
* Add or update your software on this wikipedia list
https://en.wikipedia.org/wiki/List_of_Linux_audio_software
* Chat with your developer-peers on freenodes IRC channel #lad (
Libre/Linux Audio Developers )
Miscellaneous
* How to give version numbers: Semantic Versioning https://semver.org/
* Provide release notes and a CHANGELOG
https://keepachangelog.com/en/1.0.0/ ("Don’t let your friends dump git
logs into changelogs.")
* Provide a real release as tarball and/or Github Gitlab release
(resulting in a tarball). Distributions want a stable set of files for
packaging. A git tag alone is not stable.
* Check your software and information (like README, .desktop file, your
own website etc.) if it is up to date. Take inspiration from one of the
many release guides, such as
https://radek.io/2015/11/23/release-checklist/
* The Documentation Compendium: "Why must you document your project? -
Various templates & tips on writing high-quality documentation that
people want to read."
https://github.com/kylelobo/The-Documentation-Compendium#why_document
* Does your software still create (dot-)files directly in the homedir?
Start supporting the XDG Base Directory Specification
https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@xxxxxxxxxxxxxxxxxxxx
https://lists.linuxaudio.org/listinfo/linux-audio-user
