The number of people isn't zero. Before we commit and cut a new release, we need to be able to explain what that upgrade path is.
If this is just migration storms then it's not worth cutting a new release - 3.0 was doing that anyway until very recently. If it fails to start that's a much bigger problem, but I don't see why (without testing this myself first) why it would fail to start on the minor version upgrade. Can someone explain why we get unknown cfid just be changing the digest order? -- Jeff Jirsa > On May 31, 2017, at 12:34 AM, Stefania Alborghetti > <stefania.alborghe...@datastax.com> wrote: > > The patch for 13559 is available if we want to release it in 3.0.14. The > tests are still running but I don't expect problems. We need a reviewer > however. > > Releasing the patch in 3.0.14 will cause problems for people that deployed > 3.0.13 and upgrade upwards, but the schema will agree once the rolling > upgrade is over. There shouldn't be too many people with 3.0.13 in > production however, since upgrading to 3.0.13 is broken in the first place. > > Our upgrade tests totally missed this, so they should be checked as to why > this is the case. > > >> On Wed, May 31, 2017 at 12:34 PM, kurt greaves <k...@instaclustr.com> wrote: >> >> On 31 May 2017 at 03:41, Jeremiah D Jordan <jeremiah.jor...@gmail.com> >> wrote: >> >>> If 3.0.13 causes schema mismatch on upgrade, then maybe we should pull >>> that and release 3.0.14 once 13559 is fixed. As that is a pretty bad >> place >>> to get into. >> >> >> i think that would be a good idea >> > > > > -- > > <http://www.datastax.com/> > > STEFANIA ALBORGHETTI > > Software engineer | +852 6114 9265 | stefania.alborghe...@datastax.com > > > [image: http://www.datastax.com/cloud-applications] > <http://www.datastax.com/cloud-applications> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
