Ron Mayer <rm_pg(at)cheapcomplexdevices(dot)com> wrote:
> I could imagine an enterprise plan that says "we'll upgrade to
> the current production release in January [after christmas sales]";
> or "we'll begin to upgrade the January after [feature-x] is in
> production".
>
> But in neither case does it help my long term planning to know if
> the current version January release is scheduled to be called 8.4
> or 8.5 or 9.1 (which is really all that the current system helps
> me predict).
It would help with that if you didn't plan on features which had not
been committed, and the release date didn't slip. It's been a little
embarrassing at times to have told people not to try to mitigate
performance problems on the application side because I've confirmed
that the semijoin / antijoin code already committed to the 8.4 release
solves the problem, and the release was expected around the start of
the year.
Ultimately, I don't know that it makes sense to plan on any
feature until its patch is accepted, so the best you can do is try to
plan on when the accepted patches will become available. Almost by
definition, if you want a guarantee that the feature will be in some
release, the date of the release becomes unknowable in advance.
-Kevin