Then just use a skeezy-ass download site like RapidShare, which I generally won’t ever bother with. Google Code and Github and the like are for sharing source code.
If you want to put up the ready compiled JAR and a source archive (which I see you’ve done), then you could ignore the version control entirely. You can even hide or change the source tab from the admin tab (as I’ve done with JAudioLibs in my sig).
Using these sites to distribute binary artifacts only is abusing the spirit of the service. Only on sourceforge (and of course savannah) would it be against the terms of service, googlecode and github don’t care, but without putting too fine a point on it, it’s not very nice.
MIT, BSD, Apache are of this nature.
Actually, it is against GoogleCode’s TOS and they will take you down if you don’t distribute code - you should see all the take down requests in the mailing list! However, you can just put a zip of your source files up in the Downloads section. You don’t have to use the version control systems at all.
I have to go against that. You should start using Mercurial or Git right now because it seems than it is the future. SVN will died. In fact it’s not more complicated, it is as easy to use and it’s more practical for sharing code. What will be hard is to switch to Git/Mercurial once you learned the SVN way to share code.
we had to use SVN twice for some projects, and we never going to do it again
I actually had a list of bat-shit crazy errors making it impossible to work.
in the second project we had like 4 programmers for 4 months or so - after some time, I was the only one doing SVN updates, the downloaded the, but NOBODY else ever committed anything, because they were all afraid / annoyed and we merged the code manually so to speak
http://img208.imageshack.us/img208/6272/picture1xyi.png
Had to wipe google code once - and starting new wasn’t even straight forward since it destroyed the trunk folder too…
Git seems attractive, but right now, especially after SVN no one wants to really learn Git
Right now we have our own server and just upload .rar files and stuff
Git is used for the Linux Kernel. The java source is in mercurial. They work. SVN changes backend storage formats frequently, and stuff like this frequently happens, though usually just when switching storages. It’s also one reason I don’t really trust bzr, though they don’t seem to have gone through the same epic failures SVN has.
I have uploaded the source, both as a jar and in SVN, but I’ve managed to create 2 copies of the source in two different folders, and I don’t know how to delete the old one.
Actually, the source private, the tab is just hidden. You can still access the source by adding “/source/browse/” at the end of the URL: http://code.google.com/p/java-audio-utils/source/browse/
Solution: don’t use SVN.
Many people (myself included) won’t bother with a library if it’s SVN-only, or if it’s on googlecode.
For reasons like those listed above - SVN is historically very buggy, and Googlecode has a lot of constraints that make it a pain to work with.
Github is free, very simple to use (they give you copy/paste instructions to type in), and lets you do just about anything. As a user of the library, it also makes it trivial to “fork” the library and do custom fixes / changes.
So … use github.
Really??? Considering there’s no source in there, that would be hard! 
I mentioned “hiding” the tab, not that it wasn’t accessible. (Source is available under Downloads, before anyone complains)
Incidentally, I am using the source repo to host the JavaDocs, and another big plus for Mercurial (at least on GoogleCode) is that is sets the mime types automatically so that you can actually browse it properly.
It’s about as easy to “fork” (well “clone”) a library on GoogleCode as long as it’s using Mercurial. Not using a library because of how it’s hosted seems daft to me - I’ll use it if it actually works. And if I need to fork it, I’ll just download it and host it elsewhere / privately if necessary.
I always sigh and roll my eyes a little when I need source for a library and find it’s on svn, but I don’t think I’ve ever given it an outright miss. I just have to make sure to take the extra step to delete all those &@*(# .svn directories that litter every single folder in the checkout so they don’t pollute my grep results (the main reason I check out library sources in the first place). Then of course updating it means having to re-check-out again to get those folders back… yeah, svn sucks, but then again not having source sucks more.
For java, I’d rather people just put stuff on maven with a source jar, which my IDE downloads and associates automatically, AND I know the source I’m looking at is the right version for the library version I have. Doesn’t help for the current dev branch I guess.
Why not just ‘svn export’?
I always forget about svn export. There’s a few trees I do want to keep up to date, and they’re large, so I do want to keep them checked out. Grepping the sources with ack is also useful, since ack is smart enough to skip CVS and subversion directories.