Ron Mayer <rm...@cheapcomplexdevices.com> writes:
> Tom Lane wrote:
>> I think we used to do it more or less like that, but people didn't like
>> it because they couldn't do any long-range planning.
> Does the current system help long-range planning?
> 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".
You have forgotten the context. This discussion is not about end-user
planning, it is about developer planning. The issue is whether a
developer should work on feature A that he thinks will take about X
months to finish, or feature B that he thinks will take Y months.
For this purpose it is useful to have an idea of how long it will
be until the next feature freeze. How long after that the release
will actually hit the street is interesting, but not directly relevant
to whether he's got a chance to get the feature in.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
