The naming convention depends on your organization's development style. The most important part about using naming conventions is to have a naming convention. It doesn't really matter what it is, so long as there's an easy way for people to go back and look them up.
For example, at one place I worked, we had a deployment exactly every two months, coordinated across multiple integrated platforms. These deployments were managed by way of ant scripts, and each deployment was tagged in our code repository by way of branches (they should have been tags, but, it was their established convention by the time I showed up). This bundling was also necessary because deployments could easily take many hours (a single run of unit tests was 50+ minutes at one point).
Where I'm working at now, our deployments take about three to five minutes, so we deploy on an as-needed schedule outside business hours, and usually deploy each story independently. In that case, our deployments are simply labelled the same as the feature or bug they're named for in our agile environment (e.g. US-12345 is a user story, and so would have a matching change set).
The point is to be consistent. If you're deploying once every month or so, you might consider using the term "version", even if it's really just a release date (so version 2016.03.10 is the version deployed on March 10th of 2016). If you're releasing a feature at a time, you can use the story number(s) from your other system. Alternatively, if you're a feature-based development team, consider releasing each feature as a version (e.g. "Deduplication Manager v2015.02.20" is a specific feature released on a specific date).
One recommendation that I'd have is to delete failed deployments. This only serves to clutter up the history and make it harder to find deployments you're interested in. You might keep track of them elsewhere, but usually failed deployments have no modification effect on production, and so are just failed attempts.