Search code examples
open-sourcereleaserelease-management

What are the best practices for releasing an open source project?

We have a pretty cool little web framework that we have used successfully on dozens of client projects. We are planning to release this software to the community. However, I am wringing my hands about what should/should-not go on a new open source software project page. What are the things the site must have? Docs? A Wiki? A link to download? What else?

And, a related but possibly different question is how do we begin marking release numbers. All we use internally is the SVN stamp. Is there a good way to determine when to start calling something version 0.9 versus 1.0 and 1.1 and so-on?

Solution

  • You can get an idea of what's required by what open source project hosting sites provide:

    • A web site which acts as the "one stop shop" for the project
    • Docs, potentially in wiki form
    • A source repository allowing browsing, anonymous checkout, and authenticated and authorised commits
    • Issue tracking and new feature requests

    As for version numbers... I don't think anyone's worked out the best way of doing that yet :) With a bare minimum of thought, I'd consider:

    • v1.0 should be ready for production use
    • Major version number changes can completely lose backward compatibility (if necessary - hardly a goal though!)
    • Minor version number changes should usually be mostly compatible - deprecating is probably better than removing/renaming bits of API
    • Smaller-than-minor version number changes should only include minor functional additions (if any) and bug/performance fixes