openstack-poc team mailing list archive

[Ewan Mellor <Ewan.Mellor@xxxxxxxxxxxxx>]

> From: Chuck Thier [mailto:cthier@xxxxxxxxx] 
> Sent: 29 March 2011 22:37
> To: Ewan Mellor
> Cc: Soren Hansen; openstack-poc@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Openstack-poc] PPB Meeting
>
>
> > It would be a problem if you start to make upgrades hard.  If someone wanted to upgrade once a 
> > year, then a monthly release cycle means that they will have to upgrade from version N to 
> > N+12.  Do you think that would work?  Is the Swift QA process good enough that it checks all 
> > upgrades from N to N+X for all X in [1, 12]?
>
> > If the answer is yes, then that's awesome.  If the answer is no, then we could alternatively 
> > think about some form of "LTS" scheme where only upgrades between LTS releases are tested / 
> > supported, a là Ubuntu.  That would work.  My concern here is with enterprises: they would like 
> > to deploy Swift internally, but they'll laugh nervously if you mention a 6-month upgrade cycle, 
> > and they'll just walk away if it's much quicker than that.
>
> Well the reason for doing releases would be to actually prepare code to release to the production 
> cloud files systems, in which case it better be well tested :)  We will also have to upgrade at 
> each release as well, so that *shouldn't* be an issue.  I would also like to clarify that overall, 
> the process would still be the same that the project would still be tracking to an openstack 
> release (blueprints, etc.), with just more relases in between each openstack release.

That's not what I meant.  I'm sure that your "N to N+1" upgrade will work perfectly.  The question is whether someone else's "N to N+6" or "N to N+12" upgrade will work perfectly.  Everyone else will be upgrading more slowly than you, which implies that they are skipping revisions when they do so.

Cheers,

Ewan.