I just like to comment that having public repo doesn't necessarily mean you suddenly have to deal with issues piled up by others, although in recent trend repo providers do encourage that kind of open communication (On github, I can turn off issue tracker but I don't know how to turn off pull requests).
Even using private repo, you still get bug reports, feature requests and patches via email, or (worse) stumble upon a blog or tweet complaining something isn't working for somebody. The reason I moved to public repo for my projects was that I got tired of dealing with patches manually - sometimes people sent patches against the release which was already fixed in my repo or had conflict with HEAD; sometimes I couldn't reproduce the problem so I had to send provisional patches to the user reported a bug to check out if that would address the issue. With public repo, I could just say "give me a patch against HEAD" or "I push a potential fix on a branch so check it out". It's so much easier. But again, this all depends on what kind of feedback you're getting, or how often your releases are, etc.
A source code repository can help someone find a bug more easily, and "preprocess" the bug report with more info for you, like "Hey, you broke such back on December 3, 2014---all you have to do is revert that commit's change to foo.c, and keep the other changes."
Users can run "blame" to find out which commit touched what line of any file.
Of course, you can debug a flat tarball, but it's sometimes better with the history. Particularly in cases when something previously used to work (users are running into a regression). If all they have is the previous release tarball and the new one, there are too many changes which could be responsible for the breakage.
> then I upload tar.xz's of the project for each "release".
All I do is push the release's git tag to my public repo, and the CGIT web front end automatically creates .tar.gz, .tar.bz2 and .zip download links for that tag:
$ git tag frumly-widgets-2.3
$ git push --tags
> If I was going to use a public repository, I think I'd end up using CVS.
Thus, exposing a public version control repo is too uncool for old school, but if you use some unfashionably crappy old version control system, then it's acceptable.
Result? Nice discussion. Opportunity for folks to learn something new.
And yet, your comment is gray from down votes. Since it would look bad for you to complain about that, I will: That sucks.
Having a repository where many people can come and open issues puts a burden on my shoulders - I'll look at the page and see that I need to fix <some number> of issues, otherwise I'll look bad, or people will stop using my code.
Releasing my code in releases (so that everyone is on one release, or not on any release at all) means that I don't have to deal with people who've cloned the code half-way through the implementation of something large and complained that it won't run, or that it's full of bugs.
Releasing releases has been a solid model for me, especially as I work alone, or with a maximum of two or three other people at once.
If I was going to use a public repository, I think I'd end up using CVS.