None of your current examples are really valid epics. They are actually labels, and you should think of them as labels for release targets instead.
To use epics properly, you should treat them as large user stories. You should use epics as inputs to release planning, but not as a substitute for building a release plan.
It's also worth noting that vague labels like "beta" and "launch" don't communicate much about the actual feature set that your milestones are intended to deliver. Feel free to use such labels when appropriate, but understand that they aren't a substitute for tracking features or estimating delivery dates, or for communicating about them.
Labels Aren't User Stories or Epics
Broadly speaking, an epic is a user story that is too large to fit within a single agile iteration. It is not really supposed to be a different classification; instead, it represents a different level of granularity.
The most common user story format is the Connextra format, which describes the who, what, and why of a feature:
As a <who: the archetypal user or value consumer of the feature>
I want <what: a synopsis of the feature>
so that < why: context to frame the solution space>.
So, if you take the agile approach to epics and view them as multi-iteration user stories, neither of your label sets really qualify as either stories or epics. You should refactor them until they do. Plan on refining the epics into a set of more granular user stories when they come into scope for planning, such as within Scrum's Backlog Refinement or Sprint Planning meetings.
Within JIRA—which is at heart a ticketing system, and often imposes non-agile thought processes on its workflow as a result—the system encourages you to link user stories to epics. However, it still provides the fields to describe epics in user story format, and the ability to track stories independently of epics. Don't treat epics as issue labels; leverage JIRA's features to treat epics as multi-iteration features linked to more granular stories, and use versions for release planning.
Release Planning and Epics Aren't the Same Things
In your question, you define releases such as "beta" and "launch" as possible labels. However, an epic and a release aren't the same things.
As described above, an epic is a multi-iteration, semi-granular feature set. Epics, when estimated properly, can help with release planning but are not intrinsically milestones or releases.
Agile release planning is done by estimating how many iterations it will take to address the stories related to that feature, based on estimates of the stories' complexity and the team's average capacity. To the extent that a well-articulated epic can be estimated, you can certainly plan releases around the completion of certain epics, but thinking of them as releases will lead you to the Dark Side of Agilish™ very quickly.
Because JIRA is a ticketing system, it often leads users into thinking that epics can be estimated with granularity by simply rolling up linked story estimates or assigning due dates. You can certainly assign due dates to things in JIRA, but this isn't really the same thing at all.
People do all sorts of things in JIRA to deal with release planning. The version field is usually the right place to put release labels, and also the right way to apply "Fix for Version" on each JIRA issue targeted at a specific release. However, you should not rely on JIRA itself to define your release dates. You should use an iteration-based methodology to identify the right targets for your versions, and always remember that agile estimates forecasts rather than money-back guarantees.
Vague Labels Don't Communicate Effectively
When you define a label such as "beta" for your project, it's important to understand that this is shorthand for some presumed-viable feature set. However, simply calling something a beta doesn't really communicate the planned feature set very well.
If you're going to label your milestones and release targets, rather than taking the more agile approach of releasing each iteration, then you should make sure you're communicating effectively about the expectations for each label. When possible, give the label a useful name like "messaging release" or "sign-up release" that the team presumably understands even in shorthand.
If you must use non-deterministic labels to represent release targets in JIRA, consider encoding them into the JIRA versions (e.g. foo-v1.3.5-beta1) and component fields of your issues. Some people also use a primary JIRA issue with tasks and sub-tasks to track the planned contents of a particular release.
In any case, while it can be useful to talk about alphas, betas, and launch targets, the value of the discussion is in adjusting scope to fit date targets or moving dates to fit current estimates. There is almost no intrinsic value in such labels other than as shorthand to remind everyone of these discussions, so you need to ensure that you're not simply letting the label stand in for actual communication.
If you're using meaningful labels, and having discussions around what everyone can expect from the milestone a given label represents, then almost any label will do. However, many JIRA users mistakenly allow the ticketing system to replace this type of collaborative communication.
Tickets (and labels applied to tickets) are for tracking. They are not the most effective way for teams to communicate or collaborate. Effective agile implementations value direct communications more than artifacts such as ticketing, so be sure to use JIRA tickets to support your agile processes rather than allowing it to define or drive them.