There is a common problem with software - quality, resources, or date - pick two. Resourcing is hard to change frequently. So it is frequently a question of date versus quality.
Life is rarely black and white, so its really how far to you turn the dial. My personal bent is to lift quality over date - release it when its right. That does not mean you can ignore dates. For M2.0.0 we had the dial turned hard at date because external statements around date had been made in the past and not met - we needed to get M2.0 out. But it is out now, so I lean towards turning the dial back towards quality a bit more. (I say "I" here as the final decisions involve multiple people - I can only comment on my personal bent here, not give company commitments.)
Also relevant are things like reducing the QA duration for patch releases (more and more and MORE test automation), so we can release patches with lower cost and thus more frequently. That is the direction we are going. In the case of 2.0.3 some important things came up that we decided we had to address. As we continue to increase test automation, I hope to get those conversations to be more like "something important came up - okay, lets release the current work and release it in a new patch 2 weeks later (end of next sprint) rather than delay the current patch". M2 is already a lot better than M1 here, but that does not mean we are satisfied.
So apologies for wait for 2.0.3. Our direction is to make more frequent, smaller, patches released with M2.x to respond more rapidly. We have set our course. But the journey is by no means complete. The investment on test automation (to reduce manual testing overheads) is an ongoing objective. We need to balance that against everything else we also want to get done.
