Have a Beta/Test and a Stable channel

[Pedro_Bidarra]

Over the last two updates I noticed that there are always users that have problems, right now, with 2.0.1557, I see that some onboard chips are giving users problems, which are not minor, they are unable to start F360.

So, my suggestion would be to have a two tier approach, where you opt-in into the test tier, you get the latest-greatest before everybody else, but you also venture yourself as a guinea pig.

A week (?) after, those on the stable channel get the update, by then big issues should have been resolved, if they haven't the update is delayed until they do.

This second tier would be recommended for people that favour stability and that their livelyhood depends more on F360 working. Or, say, you are doing a very important project and so you flip the switch to the stable channel. 

There will always be a high percentage that will want to have the bleeding edge, so there will always be a lot of 'testers'.
Right now, we are all on the test channel. 🙂

[roambotics_scott]

I'm told that several of the crashes that I've encountered recently are actually fixed and getting rolled out with the next major release.

I understand the need for ensuring new buids work but it would be really awesome to have a «hotfix» branch with new / patched releases coming out as soon as they're ready and validated.

The current state (fixing things but not rolling them out for months and letting users crash or asking them to tiptoe through a minefield) can be extremely frustrating.

[Anonymous]

Absolutely agree with this. 

A significent benefit to ADSK would be that you have a much larger test pool for the changes, who presumably have "checked the box", before they are released to the less understanding, more vocal masses. 

[Anonymous]

This seems like a great idea! Lots of modern software have multiple channels, so the major issues can be worked out on a Beta release before releasing the Stable release.

Too often with Fusion, you see these huge action-packed updates roll out all at the same time, and then the forums are flooded with bugs and issues. With a separate Beta and Stable channel, you could help the "professional" clients to avoid those silly bugs and errors where they could cause real time loss and damage to worflow in a company (versus the casual users for whom it's only a minor annoyance)

Hopefully Autodesk can adopt this format!

[roambotics_scott]

FWIW, I'd love to have access to the internal builds (or something closer to bleeding edge) and I'd be a lot more tolerant of flakiness if I wasn't on the «stable» branch. 

At this point, I can't even start up F360 (OS X 10.11 beta build 15A226f), so anything that got me closer to a usable state sooner would be awesome.

[zodiaceng]

I definitely like having updates and new features, which is part of why I switched entirely to F360 however the past couple updates have caused multiple delays on my end as far as actual production goes. Lost three days of work being down due to it now, one being unable to upload anything while maintenence on Saturday and yesterday as well as today being down due to graphics card failures, which worked plenty fine before the update. Home computer wouldn't handle the last big update so I purchased an entirely new computer which worked until this update and now that one is down now as well. 

I've got a machine shop that relies entirely on being able to import customer files, modify as needed and program to keep the mill going. As of right now its the third day in a row being down.

I love F360 but I need something more stable in order to proceed with it. 

[kellings]

I love this idea. I've been doing it with Windows 10 on both a PC and my phone. 

[yoshimitsuspeed]

I absolutely agree with this. Aotodesk has stated that they do all their beta/development testing in house and don't want to offer Beta or bleeding edge versions. Then every update there are crashes and failures that they didn't run into in their quarentined cleanroom environment. This is why other companies do Beta testing. To expose the software to a greater number of people/computers in different environments to make sure it's stable in all of them. 

[Anonymous]

> Then every update there are crashes and failures that they didn't run
into in their quarentined cleanroom environment.

Spot on. So many issues you could never catch unless it's open to the
public.

Doing the testing in-house guarantees your paying customers who depend on
this software for their employment will have issues and will crash and will
be unable to work. It's a severe hypothetical scenario, but it's the choice
Autodesk is making (if they are intentionally choosing not to bug test)

[roambotics_scott]

Seriously yeah.

Not only that but it's infuriating to hear that some crashing bug you run into is not only known but has been fixed in the internal builds.. which will roll out in the next update which was scheduled for a few weeks from now but won't actually roll out for more than a month - not that that's ever happened to me personally.

Also, people in a beta stream can't really complain about software stability because those should be expected, so you'd also innoculate people like me against bitching too much.

[Anonymous]

"so you'd also innoculate people like me against bitching too much"

It's like a waiver to remove your rights to bitchy about bugs... Sigh me
up! 😛

[roambotics_scott]

Gah - «inoculate»

[Pedro_Bidarra]

Yes, when you are in a Beta channel you are more tolerant to bugs, much more than the current situation where we expect stable/production ready software from the current release and when we don't get it it affects the image we have of the software.

So my suggestion has indeed a bit of social engineering built into it, while techically it just adds some conservativeness by delaying for a week or two the mass deployment.

My initial suggestion wasn't to make internal builds available to beta testers, but to have what is now the current build (2.0.1557 in this case) be considered beta/test until major bugs are ironed out. But I wouldn't mind if this beta channel has more intermediate builds, what i think is more important is having a stable channel that is more reliable.

[roambotics_scott]

I'd not go so far as to release every internal build to the beta channel, but I'd definitely release the betas sooner and more often than the public builds / not just a week or two early.

I'm not sure how F360 does version control but there should be a HEAD / Master branch with bleeding edge (for internal builds with feature branches merged in), feature branches for everyone internal developing new things, STABLE / RELEASE which gets all of the well tested commits and goes to the public builds, and a BETA branch that gets automatically checked out, built, tested, and rolled out to beta testers once a week or two.

Whoever is in charge of merging should only merge the STABLE / RELEASE from tested code in the BETA branch.

It'd be nice (though probably very challenging) to also have a git-blame type of thing integrated into all of the builds so once a crash is detected it can be pinned down to all of the code commits where it could have been introduced (of course that's going to be difficult when there are things that trigger crashes downstream and if it's not done right it'll likely do more harm than good).

[Pedro_Bidarra]

"Status changed to: Gathering Support"

It was already "gathering support", 18 kudos isn't enough support? 🙂

[roambotics_scott]

That's another problem with the «voting» charade - at least if it were run by a benovelant dictator, the confusion disappears.

[yoshimitsuspeed]

This is BS and this $#!! is exactly f!@*# why.
http://forums.autodesk.com/t5/design-and-documentation/crash-after-crash/td-p/5826760

this is why you do a beta channel. People like me can't afford to wait who knows how long for you to patch faulty software.
This isn't the kind of thing that should need to be voted on. Not that the votes here mean S.
This happens every damned update in some way or another.
Not only that but as long as you guys keep focussing on stupid crap to update I don't care if I have the bleeding edge version. I might if you implimented GD&T, sheet metal or actually useful stuff but since you don't, at least give me a nice solid stable featurless program that I can use.
FEA is awesome but it will need to be much more stable and proven to be of any use to me so it's not currently. All the other stuff that was in your little (what was updated) video I couldn't really care less about.
You know what is important to me? Being able to open my drawings when I need to. Not having crashes all the time. Being able to do my work without loosing an hour for every three of actual productive work I get done.

I really wish you guys would do more development that actually mattered to me but either way it's all completely irrelevant until you get somewhat, kind of a little bit stable software.

[roambotics_scott]

Man I'm sorry to hear that, Yoshi. I so feel you there.

Really strongly seconding the beta channel thing, @colin.smith @sanjay_jayabal @any other PMs ? (just seeing two makes me wonder if being a PM here isn't like being a VP at Silicon Valley Bank, @carl_bass)

Treat the beta channel like a staging release (even do a staging deploy for AWS) - and maybe even let people have a production and beta version on the same machine so they can test the bleeding edge and then have a stable branch to fall back on when they run into issues.

Push nightly (or at least weekly) builds out onto the beta channel and then when you have one that's rock solid (zero crashes observed) after testing for at least a week, then rotate it out to production.

[Pedro_Bidarra]

When I published this idea, 2 months ago, we were at R2.0.1557, now we are R2.0.1628, and we are having the exact same symptons we were having before, the program not being functional for some people after an update, and these people being very angry because they rely on the software.

"Gathering Support" is a strange limbo, isn't 21 kudos enough support? At least enough to receive an official response, positive or negative.

[roambotics_scott]

Seriously.

In their («I understand» not «it's ok») defense, I suspect the problem is that the app and cloud back end are a pot of spaghetti that can't be easily broken apart (although they do have internal builds so it should just be a matter of duplicating that and adding another release stage).