I would just put that clearly and prominently in the readme.
"Released open source in case this code is useful to you, but there will be no support, no further releases, no bugfixes, and no response to issues. If you find this code useful and would like to modify it, please feel free to fork it."
[I forget if Github lets you turn off 'Issues' entirely, but if it does, do so.]
This way people know what they're getting into when they use the code. You have no _obligation_ to do anything, and it's better to share the code as examples for others trying to do the same thing than to keep it private because you don't want to support it.
But people may assume the code is supported, and regardless of what they assume, they can make a better decision on whether to use it or not (and use it how), if they know it's unsupported, and it is the right thing to do to let them know up front. If I found useful code, but knew it was 'abandonware', I might or might not choose to use it anyway, but that knowledge would effect my decision.
If you have code that you released without making that clear, and _have_ been supporting half-heartedly anyway (setting some expectations), well, contrary to what I predict will be the HN consensus, I think you do have some responsibility to your users. But you still aren't trapped forever in indentured servitude. Wind it down gracefully, maybe find someone else to take it over (have you accepted a pull request from anyone ever? if so, that person is a good candidate :) ), maybe keep responding to issues for a little while after you make the announcement that it will soon be abandonware. Or if you're completely burned out on it and just don't have time, then stop cold turkey if you have to, but post in the README what you're doing. (Don't delete the repo, that would be very rude to current users).