Beta Frequently Asked Questions

Beta Frequently Asked Questions​

1. What is the beta?

The Unity beta is a version of the software that is still in development and hasn’t yet been approved as a full release. This means that it has new features and updates, but it also still has bugs that may cause issues for users.​

The beta is open to feedback on the new features and updates. Major feedback (feature requests, for instance) is not what the beta is meant for.​

2. Why do you have a beta program?

We make the beta available to Unity users because while our QA teams are diligent about frequently testing new versions of Unity against a variety of projects, they are only able to test a fraction of the tens of thousands of projects that are constantly pushing the engine in different ways. The beta allows users to test their projects in upcoming versions of Unity to provide peace of mind and ensure that the engine will continue to work for them.​

3. How do I become a beta tester?

All you have to do to become a beta tester is download the beta version and begin developing! We strongly recommend upgrading existing projects to the beta to test for bugs and regressions that may affect your projects.

Be sure to backup your projects before upgrading them to the beta. Using the beta for game production is not recommended.

For more detailed information on how to be an effective beta tester, see this forum post.​

4. I tried the beta and found X bug - how do I get it fixed?

You will need to submit a bug report. Please see this forum post for a step-by-step guide to submitting a high-quality bug report that will enable our team to address your issue.​

5. How do I submit a bug report?

Open the bug reporter by selecting Help → Report a Bug in the menu while running Unity. The bug reporter can also be found installed next to the editor in the program folder. It will launch automatically if you experience a crash.

Fill out all relevant information in the bug reporter and attach a project folder with the smallest project that allows you to reproduce the issue, then hit “Send.” For more information on submitting a high-quality bug report, take a look at the Guide to Being an Effective Beta Tester.​

6. How will I know the status of a bug I have submitted?

A Unity representative may contact you with questions if they have any difficulty reproducing your bug. If the issue you submit is verified and confirmed as a bug, you will be able to use the link sent to you in your confirmation email to check the status.​

7. How do I get my bug on the public Issue Tracker?

When you file a bug report, simply check “Share description in the Public Issue Tracker.” The bug will be shared as soon as it is confirmed by our team.
​

8. Is it possible to keep my bug off of the public Issue Tracker for privacy reasons?

Yes, just make sure that “Share description in the Public Issue Tracker” is unchecked. We recommend sharing bug reports to the tracker because it helps the community, but we understand that sometimes there are reasons to keep a bug private.
​

9. How do I know what beta version the fix for my bug will be in?

You can check the release notes, which contain bug numbers for the fixes contained in the release. Otherwise, the best way to determine which version the fix is in is to keep track of your bug reports and the associated project folders and test them against each new beta version.​

10. Can I have multiple versions of Unity installed at once?

Yes, though you will need to ensure that they are installed in different directories. See this page in the documentation for more information on how to properly install multiple Unity versions.​

11. What is a bug rating?

The rating system is a way for us to categorize incidents based on how good the report is, i.e., how likely is it to be reproducible and an actual bug in the system. To do this, we look at how much information is on the bug in the form of attachments and how much text has been entered in the description.​

0: Very little or no description. No attached files. User selected “First time” or “Sometimes”.
1: Very little or no description. No attached files. User selected “Always”
2: A small amount of description.
3: An attachment is present (typically a project), but little to no description.
4: A good amount of description is present, but no attachment.
5: Good description and attachments present.​

To learn more about bug ratings and how our teams address them, see this blog post.​

12. Why hasn’t my bug been fixed yet?

We receive more than 1,000 reports per week, and the process for reviewing, reproducing, verifying, and fixing is time-consuming. Our team addresses all bugs rated 4 and 5, and does their best to review all bugs rated 3 (bugs rated 0-2 are not often reproducible). See this blog post for more on how our QA teams process bug reports.

Additionally, the development latency is such that any beta release started days earlier. So, after a build is made available, there’s a really narrow window to get a fix to the next beta. In addition, our development processes need to check thousands of tests and try and make sure we’re not breaking other platforms. Even what might seem like a small change can take a little while to process.

When a bug has a fix, it’s applied to a local branch a developer has and begins its local testing with QA. Sometimes a developer will bundle a batch of fixes which will take longer to process. Afterwards, these branches must begin a code review process and automated test validation to arrive into a release branch.​

13. What happens when I submit a bug report?

When you submit a bug report, it is sent to our team as an “incoming QA incident” for QA to review. Our team uses the rating system to categorize the bugs based on the information provided in the bug report, and then tries to reproduce and verify the incidents starting with those rated 5.​

In the case that an incident is verified, the incident is converted to a bug and our team begins investigations and determining how to fixing it.​