Josh Berkus wrote:
I don't think you're listening, none of those things are problems and
so not user hostile.

Having an upgrade fail for mysterious reasons with a cryptic error
message the user doesn't understand isn't user-hostile?  Wow, you must
have a very understanding group of users.

Lemme try to make it clear to you exactly how user-hostile you're being:

1. User downloads 9.2 today.
2. User builds a new application.
3. User finds the doc page on RULEs, decides they're a nifty concept.
4. New application includes some RULEs.
<snip>

I have a proposal.

Assuming we decide to do away with RULEs, change the *documentation* for RULEs right away in all supported maintenance branches (including 9.2), saying that RULEs will be deprecated, but don't change any code / add any warnings until 9.3.

Then, no later than the next bug/security fix minor release, 9.2.2/etc, the documentation for RULEs all says that, yes we have RULEs, but you shouldn't use them on any new projects as they are going away, and you should migrate any existing uses, and uses will warn starting in 9.3.0. This documentation change can also be highlighted in a bullet point in the 9.2.2/etc release announcements. If necessary, also make reference in the docs to some tool or procedure to help find any uses of RULEs and help with the migration.

Since this isn't a code change, it should be very conservative and be safe to include in maintenance branches, and it will alert users right where they're most likely to look, the RULEs documentation, without any undue delay.

How does that sound?

-- Darren Duncan


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to