On 02/12/2010, at 9:58 PM, Daniel P. Berrange wrote:
<snip>
I think this is really viable, because it implies we need another
Err... "not" really viable yeah?
week prior to creating the pre-release where we do what we currently
do with pre-release stabalization. With a monthly release cycle,
taking 2 weeks todo a release is too much of an time sink.
IMHO, we need to have
- A official list of supported platforms / OS combinations
Yep, good idea. We should definitely have a list of "core things we support",
plus some way of communicating things also being worked up.
- Run a test build on each combination before release
Yep.
- Actually follow the 'bug fixes' only rule leading upto
release
no matter how simple the new feature might appear.
Would it make sense to branch git at the point we enter "feature freeze",
having the new branch be just for the release in question, and allow people
to continue committing to master? (I'd also think this is the point we could
generate a "release candidate" tarball for people to test if they want)
When bugs turn up in the freeze period, the fixes can be applied to the release
branch. It sounds like it _might_ also mean a bit more work, as the same fixes
will need to be applied to the master branch too.
Good/bad approach?