Are release candidates safe to use for production?

Question

In this particular case it is MVC. But, how much difference is there between the release candidate and the go live or production versions? I'd hate to build a lot on the RC and have it break or miss out because I didn't wait. On the other hand I do have dealines to meet.

Thank you.

update based on comments:

What does it really mean to have support for something like MVC from Microsoft? I'm not sure what support I would even ask for. I've always wondered this as it relates to the programming side of things. Getting support for physical server (a hard drive dies), I understand. What would I ask Microsoft for in a case like this?

Answer 1

Depends on what features you're using, whether you have the source code and whether or not the vendor's licence even allows you to go into production with it.

Having source code can mitigate issues but you would be foolish to use an unsupported product in a business critical environment.

Answer 2

Usually RC builds will have finalized APIs and UI, they just might have bugs. I'd say that it's safe to develop against, but I'd be very wary against deploying unreleased code.

Answer 3

I think No

Answer 4

I'd add that it depends upon the availability of support from the vendor if something does go wrong, which is often tied into the terms of the licence.

Answer 5

I would say generally do not use release candidates in production environments. That said, there are definite exceptions, some products are either in Beta or Release Candidate stage for a long time and can be quite stable before they reach general availability.

Answer 6

By definition, no, but you should use your own judgment based on the product, vendor, the updates it contains and what your needs are.

Answer 7

In general, wait for the production version before using. If the company developing it is not ready to put a production tag on it, how can you trust it in your production? When you are determining the reliability of your site/product, you can only be as reliable as your weakest link. The risk for most RC's is too high to gamble on.

However, there are exceptions. .Net MVC is one. The development team has released early and often to huge amounts of external developers who have found the bugs. This RC is very safe and not much of a gamble.

Other exceptions would be from similar circumstances:

• the product has had extensive testing by large groups of external users
• the company leaves products in RC or Beta mode much longer than normal, so sufficient time has passed to find bugs (Gmail for example)
• immediate support or source is available

The type of support you would need is quick response (with fixes) to any bugs you uncover. For instance, your app uses the tool DooHickey to do operation HickeyItUp. You find that the tool works great except when you use it to HickeyUp an object of type AlmostHickey. Instead it returns an error. This error causes your site to crash, and you need an answer now. Good support will tell you if you are implementing it wrong and the correct way, or give you a work-around, and/or have a bug fix to you in very short time.

Don't expect much of that level of support from Microsoft (MVC might be different due to the great team that has been so responsive). Instead you would get much of that from the body of developers that are already using it.

Answer 8

In my past life I did it all the time. Anything I deployed was based on open source components. However, I only choose components that came with good test suites.

With closed source software you just have no idea how well stuff is tested. The vendor may be using their user base as an extended QA team.

But, as Carlton Jenke says, there is always an exception.

Answer 9

I think it depends on the expected robustness of the "production" app.

Your personal website? Sure!

The state unemployment insurance application system? No.