@mattab
Even though Piwik is not stable as such, some releases are more risky than others (eg. 0.2.35). In this case we should have released under a "beta" label.
Currently the release script builds from a SVN tag. It checkouts the tag, delete some useless directories (tests/ etc.), and then packages up, copies into http://builds.piwik.org, and updates the http://builds.piwik.org/LATEST with the version number.
Instead we should have two releases (or event three?).
- the current official release (near stable)
- a beta release (if the version name contains "rc" or "beta" ?)
- a nightly build of the SVN trunk
The release could be automatically flagged as beta if the name contains beta or RC. It would not update http://builds.piwik.org/LATEST (this file is used by all Piwik installs to check what is the latest piwik release and print an "You need to update" message).
The beta could be advertised below the red download box on Piwik.org: "Download 0.2.37" and below "Download and test the beta release: 0.4rc1"
we have to release 0.4 with the beta label, and keep providing 0.2.X as stable alternative.
@robocoder
Reminder to create a 0.2 maintenance branch in svn.
vipsoft, I don't think we need a branch. In the rare probability case where we need to fix a security issue in 0.2.x then we would just backport the fix to a fresh checkout of the last 0.2.x tag, fix it and tag it in 0.2.x+1. SVN Tags are enough for us, I see branches as more useful when you know there will be many changes in parallel.
it is done, you can see the latest alpha/dev/beta/rc (any tag matching these strings) will be updated in http://builds.piwik.org/LATEST_BETA
I just don't know where to advertise this on the website at this stage, so will just not advertise it. We might want to create a "Downloads" page on piwik.org/download/ and list the two releases availables + links to the older builds. any suggestion?