openstack-poc team mailing list archive

[Chuck Thier <cthier@xxxxxxxxx>]

>
>
> 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