Ron Mayer <rm...@cheapcomplexdevices.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
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers