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
