openstack-poc team mailing list archive

[Ewan Mellor <Ewan.Mellor@xxxxxxxxxxxxx>]

> -----Original Message-----
> From: soren@xxxxxxxxxxx [mailto:soren@xxxxxxxxxxx] On Behalf Of Soren
> Hansen
> Sent: 29 March 2011 21:16
> To: Chuck Thier
> Cc: Ewan Mellor; openstack-poc@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Openstack-poc] PPB Meeting
> 
> 2011/3/29 Chuck Thier <cthier@xxxxxxxxx>:
> > Likely monthly, +/- a couple of weeks :)
> 
> I think it's imperative that we
> 
> a) don't set ourselves up in a way that forces major consumers of the
> code base (like Rackspace) to have to maintain a fork of the code, and
> b) conversely, let other consumers of the code base benefit from
> Rackspace's rapid dev/qa/production cycle.
> 
> Forcing Swift into a longer release cycle than Rackspace Cloud Files
> would be counter to both of these things.
> 
> That said, I believe it's equally imperative that if this rapid
> release cycle only benefits Rackspace, but is a problem for others
> (not sure how, but it could happen), we need to be very open to their
> needs and potentially revisit this decision.

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.

Cheers,

Ewan.