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? -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
