On Mon, Nov 28, 2011 at 11:01, Mark Kampe <mark.kampe@xxxxxxxxxxxxx> wrote: > Does this seem like the right general form for our release criteria? What > changes would you suggest? As long as we're blue-skying ;) -- at some point we should automate tests for upgrades. Simple first iteration: install previous release, add data, upgrade, test functionality, test previous data is accessible (multiply by access method: rados, rgw, rbd, cephfs fuse, cephfs kernel client) Later: To release x.y, upgrades from x.(y-1) and x.0 must work. To release x.0, upgrades from (x-1).0 and (x-1).latest must work. If these upgrades are not supported, release notes must say so. Even later: Test functionality *during* the upgrade. Even more laterer: Test extended cross-version compatibility, as in old-osd talks to new-mon, or don't upgrade clients at all, etc.. -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
