RFC: Renaming grabbers

"Mommy, why are my listings broken?"

Prompted by Joakim's question regarding renaming eu_dotmedia to
eu_xmltvse [1] I am keen to seek comments/consensus about creating a
"policy" on how we as a project handle the renaming of grabbers.

  [1] https://github.com/XMLTV/xmltv/issues/6


Protocols for renaming a grabber could include:

i) carry the functional grabber under both names (as we recently did
with sdjson) for the next release cycle, email -users/-dev and add a
notice to the release notes/readme about the impending changes, and
remove the "old" version of the grabber before making release n+1; or

ii) carry the grabber under both names for the next release cycle
*but* replace the old grabber with a simple script asking the end-user
to migrate to the new grabber, email -users/-dev and add a notice to
the release notes/readme about the changes, and remove the dummy
grabber before making release n+1; or

iii) rename the grabber immediately (i.e. before the next release),
email -users/-dev and add a notice to the release notes/readme and let
end-users notice their grabber is broken after their next upgrade.


There are probably others, but is one method any more favourable than
the others?


* The first option (carrying both for a release) delays any necessary
end-user action until release n+1.

* The second and third options require a user to migrate as soon as
they upgrade, with the second option giving run-time feedback.

I am guessing here, but I would think the majority of users run a
grabber either through something like cron, or via a calling
application (e.g. MythTV) so the chances of seeing run-time output are
probably reduced.

In my experience in PVR-land, users tend to notice future listings
gradually reducing and then look into why that is the case (either my
looking a logs/software) or posting a question.


Thanks,
Nick

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot