> > > 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. -- Chuck
_______________________________________________ Mailing list: https://launchpad.net/~openstack-poc Post to : openstack-poc@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-poc More help : https://help.launchpad.net/ListHelp
