I agree with Robert that this could be fixed in a bugfix release, but I really don't like immediately starting a new 1.3.1 vote a day after the 1.3.0 vote ends. I think it potentially gives a bad/sloppy impression to our users.
Therefore, I lean towards cancelling this RC and creating a new one with the fixes included. If there are no objections, I would reduce the voting time to 48 hours (Fri assuming that a new RC is created today) instead of 72 -or- keeping it at 72 and counting the weekend. Best, Ufuk On Wed, May 31, 2017 at 10:20 AM, Nico Kruber <n...@data-artisans.com> wrote: > IMHO, any release that improves things and does not break anything is worth > releasing and should not be blocked on bugs that it did not cause. > There will always be a next (minor/major) release that may fix this at a later > time, given that the time between releases is not too high. > > Consider someone waiting for a bugfix/feature that made it into 1.3.0 who--if > delayed--would have to wait even longer for "his" bugfix/feature. Any new > bugfixes (and there will always be more) can wait a few more days or even a > few > weeks and may be fixed in 1.3.1 or so. > > > Nico > > On Tuesday, 30 May 2017 20:21:41 CEST Till Rohrmann wrote: >> - Not sure whether it's a good argument to defer fixing major bugs because >> they have not been introduced with 1.3.0. It's actually alarming that these >> things have not been found earlier given that we test our releases >> thoroughly. >
