Hi,
On 11/29/2011 01:38 AM, Tommi Virtanen wrote:
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.
You could try to couple this to a specific version?
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)
Starting with version 0.40
Later:
To release x.y, upgrades from x.(y-1) and x.0 must work.
Version 0.60 and later
To release x.0, upgrades from (x-1).0 and (x-1).latest must work.
Version 0.80 and later
If these upgrades are not supported, release notes must say so.
Even later:
Test functionality *during* the upgrade.
Version 0.90 and later
Even more laterer:
Test extended cross-version compatibility, as in old-osd talks to
new-mon, or don't upgrade clients at all, etc..
Version 1.0
Since v1.0 would become the "stable" version you might expect users
upgrading while maintaining their data.
Does this seem reasonable?
Wido
--
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
--
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
