Image Description
Preparing your first software release
Your program works. You have tested it. You are ready to unleash it upon an unsuspecting world.
Before hitting upload, there are a few things worth checking.
Choose the version
Give the release an identifiable version and use that same version consistently in the program, download page and release notes where appropriate.
Check the licence
If you are distributing source code, make your licensing clear. Also check the licences of dependencies and assets you distribute.
Test the actual release build
Do not only test from your development environment. Test the thing users will actually download, ideally on a reasonably clean system.
Write down known problems
If you know something is broken, telling users is considerably nicer than letting each one discover it personally.
Provide useful documentation
At minimum, explain what the software does, supported platforms, how to install or run it, important requirements and where to report problems.
Keep the release
Keep a copy of what you published. Being able to reproduce or inspect an old release is extremely useful when somebody reports a problem six months later.
Then release it
You can always find one more thing to polish. At some point, if it is ready enough for the audience you have described, release the thing and learn from what happens next.
Try installing your own release
This sounds silly, but it catches an amazing number of problems.
Take the release package you are about to publish and install or extract it somewhere clean. Do not rely on the copy sitting in your development folder with all your source files, test data and dependencies conveniently nearby.
Can you launch it? Are all the files there? Does the version number shown by the program match the version on the download?
Think like somebody who has never seen it before
You know how your program works because you made it. Your users have not had that luxury.
Make sure the download page or README explains what the software does, what operating systems it supports, how to install or run it and where somebody should report a problem.
Keep the old release
Unless you have a good reason not to, keep a copy of exactly what you released. If somebody reports a bug in version 1.2 six months later, being able to run the same build can be extremely useful.
And then release it
There is always one more tiny thing you could polish. At some point, if the software is ready enough for the audience you have described, you have to let people use it.
You can fix things in version 1.0.1. That is rather the point of having version numbers!
Further reading and external resources
Want to dig into this a bit more? These are good places to go next. If anything here ever disagrees with the official documentation, trust the official documentation.