Geek Answers Handbook

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

We have a pretty cool small web structure that we have successfully used on dozens of client projects. We plan to release this software for the community. However, I am pushing my hands about what should / should not go to the new page of the open source software project. What are the things a site should have? Docs? Wiki? Download link? What else?

And a related, but perhaps another question, is how do we begin to mark 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 compared to 1.0 and 1.1 and so on?

+4
source share
6 answers

You can get an idea of ​​what is required for providing open source hosting sites:

  • Website that acts as a single window for a project
  • Documents potentially on a wiki form
  • Source repository allowing browsing, anonymous verification, and authenticated and allowed commits
  • Bug Tracking and New Feature Requests

As for version numbers ... I don’t think anyone has developed a better way to do this :) With minimal thoughts, I would think:

  • v1.0 should be ready to use
  • Major changes to the version number may completely lose backward compatibility (if necessary, this is hardly the goal!)
  • Minor version number changes should usually be mostly compatible. The downside is probably better than removing / renaming API bits.
  • Smaller version number changes should include only minor functional additions (if any) and bug / performance fixes
+4
source

In the version, I think the best place to start is the Semantic version .

+2
source

Marking of version 0.9 / 1.0 / 1.1 / 1.0.1 / ... is for marketing purposes only (in a good way). This allows your users / clients to identify whether the release is major, minor or to fix a bug, and whether you consider it mature or not.

Minimum for delivery are sources. Other results depend on how you are willing to help and support your users.

+1
source

Select a website to place the source on the first (e.g. SourceForge). Get the source there in an anonymous version control system. Get an email address so people can contact you.

Call this first version 0.1. This is due to the fact that you do not yet have documents to support the project.

Then breathe.

Then start looking for documentation, such as a wiki. After all this will be considered at a basic level of detail, and you think that the release is ready for some prime time, then go to 1.0 and start providing binary downloads.

+1
source

Make sure you think of a source license.

When I look at an open source project, one of the first things I check is a license. If the license is not a GPL2 / GPL3 / BSD style or similar, this is a demotivator for me.

A license means that people will do with it, how it can grow, and how much it belongs to the corporation that issued it. Since choosing open source, I try not to depend on corporations (which depend on their owners), I really prefer to use really free software.

Since the open source community is very sensitive to corporate power (Google seems a little immune to this at the moment), so you really need to be sure that you will receive a message that is really free on your network site and other materials that you publish about the software.

Read more on free and open source FSF definitions.

+1
source

Take a look at GitHub or Google Code. they provide a very good starting point for their own open source projects. You can describe your project, document it on a wiki, use git or svn as your repository, and provide downloads along with problem tracking and multi-developer management. A good environment out of the box to learn and use them.

For release numbers: I do not recommend 0.9 or something similar for pre-releases. Cause? What about release 1.9? Is this the 9th sub-release of major release 1 or the last release of release 2? My release standard is described here: http://code.google.com/p/tideland-eas/wiki/ReleaseStandard . I use a three-number scheme, major, minor and patch, as well as status code, alpha, beta, gamma and release date. Therefore, I can easily handle multiple issues in parallel.

Hope this helps.

MUE

0
source

More articles:


All Articles