Well, my non-official guess for the short answer is "not much." The longer answer goes something like this…
Public-beta means that the version includes new features and problem resolutions which may or may not need further refinement. It's been tested in-house and deemed worthy of testing by end-users, but may not be the "final release" for that version. There are no guarantees that it's "bug" free, though.
Non-beta releases have been met the criteria for a "milestone" (e.g. the main additions and issue resolutions have been identified and addressed), have been tested in-house and by end-users, and has been deemed to be as "bug" free as possible. That doesn't mean that there aren't bugs, but rather everything that's been identified to date has been addressed.
Basically, "beta" releases are for in-house testing, "public beta" releases (or "release candidates" to borrow another company's term) are for end-user testing, and "final" releases are milestones. That can apply to both major (x.0) and minor (x.1, x.2, etc.) revisions. After a "final" release, the process starts over again on the next version. Major revisions usually include new features, while minor revisions usually include "bug" fixes that were not yet identified at the time of the last major revision, but these aren't hard-and-fast rules.
The life-cycle is something like this (every company's different, though, so this isn't meant to be exactly how this works at Eventide):
1. initial-version release (1.0.1)
2. problem identification
3. problem resolution and internal testing (1.0.2)
4. public testing (1.0.3)
5. problem identification
5. problem resolution and internal testing (1.0.4)
6. public testing (1.0.5)
7. final release (1.1.1)
8. new feature identification
9. problem identification
10. problem resolution and internal testing (2.0.1)
11. public testing (2.0.2)
12. problem identification
13. problem resolution and internal testing (2.0.3)
14. public testing (2.0.4)
15. final release (2.0.5)
And so on…
