LicenseYour Work SearchCC Licensed Work

Software Release Procedure


This is a general release strategy for software in order to maximize its distribution. Most of this is general tried-and-tested from Open Source development on Inkscape, Open Clip Art Library, Gotmail, and other projects (Jon Phillips).

  1. Prepare a software release
  2. Issue announcement to community about an upcoming release with a general timeframe (and not too specific)
  3. If release agree upon, Tag/branch release (OPTIONAL go into freeze for 1-5 days depending on size of project)
  4. Package up release
  5. Post packages on-line
  6. Notify community about on-line packages
  7. Give 2-7 days for testing of packages
  8. During the 2-7 days write press release and announcement on public wiki page
  9. Let community review press release and announcement
  10. Get agreement on release from core developers on a project
  11. Release packages on main site
  12. Release news to contacts, related lists and websites (freshmeat, sourceforge, prweb.com, desktoplinux, linux world news)

Contents

Notes

Time-based vs. Goal-Based

If an open source project is too time-based, there is a risk of scaring off developers who already have time-based development at their jobs. Remember, 70% of Open Source Developers do Open Source because they want to learn and have fun.

A great strategy is to have a roadmap with milestones and tasks which people can add or use as a guide to find some itch to scratch, and then have general times for releases in mind. If the community doesn't hit the target, that is cool, go with the flow and move back the release.

Social Protocol

real vs. virtual

Generally, treat developers and people in general just as you would in the real world, if not better.

promote contribution

Always promote users to contribute and plug into development, help revise your work, and/or show where to go for more information.

social problems

Core developers should correct social problems off-list.

Feature Freeze

For large projects it is generally best to have a feature freeze where the community is to focus on bug fixes and stability, while major features are frozen. This is a social contract and not a policed/technically-enforced action generally.