On Sat, May 25, 2013 at 4:39 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
> There are a number of changes we'd probably like to make to the way
> things work in Postgres. This thread is not about discussing what
> those are, just to say that requirements exist and have been discussed
> in various threads over time.
>
> The constraint on such changes is that we've decided that we must have
> an upgrade path from release to release.
>
> So I'd like to make a formal suggestion of a plan for how we cope with this:
>
> 1. Implement online upgrade in 9.4 via the various facilities we have
> in-progress. That looks completely possible.
>
> 2. Name the next release after that 10.0 (would have been 9.5). We
> declare now that
> a) 10.0 will support on-line upgrade from 9.4 (only)
> b) various major incompatibilities will be introduced in 10.0 - the
> change in release number will indicate to everybody that is the case
> c) agree that there will be no pg_upgrade patch from 9.4 to 10.0, so
> that we will not be constrained by that
>
> This plan doesn't presume any particular change. Each change would
> need to be discussed on a separate thread, with a separate case for
> each. All I'm suggesting is that we have a coherent plan for the
> timing of such changes, so we can bundle them together into one
> release.
>
> By doing this now we give ourselves lots of time to plan changes that
> will see us good for another decade. If we don't do this, then we
> simply risk losing the iniative by continuing to support legacy
> formats and approaches.
Huh. I don't think that bumping the version number to 10.0 vs 9.5 is
justification to introduce breaking changes. In fact, I would rather
see 10.0 be the version where we formally stop doing that. I
understand that some stuff needs to be improved but it often doesn't
seem to be worth the cost in the long run.
merlin
