Probably the same as T60733 as well as T59333. The model in question here has several faces with >170 vertices (massive n-gons).

It changed to bpy.ops.preferences.addon_enable a few days ago. Docs just haven't been updated for it yet.

This is not a bug right now, but rather the feature isn't coded yet and is a known limitation: https://wiki.blender.org/wiki/Reference/Release_Notes/2.80/EEVEE (see the Limitations section at the bottom)

CTRL+B in edit mode is Bevel -- and the build yesterday had a crashing issue with Bevel for a few hours. A new build was released a few hours later -- can you try redownloading and trying again now?

A new build with a fix for this issue was just built. Give it another download/try now.

A new build with a fix for this issue was just built. Give it another download/try now.

A new build with a fix for this issue was just built. Give it another download/try now.

The bug tracker isn't a support system. A better place to troubleshoot this will probably still be with the addon author - try contacting him again. For instance, your second picture clearly indicates an old set of files attempting to be installed -- beyond the "upgrade to 2.8x required" message, the error message itself references "scene_update_post" which is no longer in 2.8 and is no longer in the addon developers git repository at that location either. Double-check where you got your zip from.

The lack of AA, right now at least, is due to reverting to the old way of drawing lines since there were so many complaints about wireframe (like on devtalk).

No repro with today's git. Seems this was fixed shortly after your build. Try again with the Feb 1 build, which should be available later tonight when it drops.

The top row of tabs (called Workspaces) will automatically switch into the appropriate mode (pre configured for them). Modeling and UV Editing will auto switch to edit mode for example. Sculpting will auto switch to sculpt mode etc.

Yes, you would have to implement a do_version converter if you went with my proposal to handle older files automatically. Maybe percentage makes more sense I guess? I'll leave it to you folks to make final determination; just sniffed weird at first glance :)

Rando comment: For UI ranges controlling values which have no obvious unit or real life equivalent, should the convention be to have a slider between 0 and 1 in most cases? I ask because having something like Bloom intensity stop at 0.1 (even though the input allows higher numbers) would almost feel like a bug that someone would end up reporting. Why not scale accordingly and map ui 1.0 == 0.1 behind the scenes etc?

I thought Brecht changed the default to 1.0 as part of c1d82e58492?

Try running blender with the --factory-startup command line option and see if that solves the problem. If it does, you should remove the 2.80 directory under "%APPDATA%\Blender Foundation\Blender"

This is a duplicate of T58748

I can repro with today's git. Here are the steps

It looks like some changes to the default startup.blend in recent builds has changed the Auto Perspective default to OFF -- is that by design?

Seems to still be an issue for the buildbots:

This is due to distance between your near/far clip plane distances. It ranges from 1 millionth of a meter to 1000 meters in your video -- even 2.79 did not handle this distance (other visual issues) and 2.80 is even more sensitive to it. A more appropriate range will be centered around the type of object you're modeling.

Most likely a duplicate of T59608

Most likely a duplicate of T59608

Confirmed with a build from today.

Just like in 2.79 this is controlled by the User Preferences -> Interface -> "Auto Perspective" option. The only change is that this is now enabled by Default in 2.8

I believe this was fixed as part of 4c41f8e9ad3 and f40a88a4ba9

This can be easily observed with the default cube.

It still flipped to the top for me after an install with most recent git pull. Can anyone else still repro?

Might be a duplicate of T57620 (or at least heavily related?)

I seem to be able to repro here -- indeed it looks related to snapping.

Perhaps related/duplicate of T57485

Confirmed here as well. Looks like it's the same cause as T57312

Rebuilt from scratch after my previous comment to know for sure. But I can repro OP's issue when using a Debug build (compiled from source) which allows the assert to hit. I was also unsuccessful in creating a repro .blend; the act of saving and then re-loading the .blend seems to fix the issue. Perhaps the mesh loop/normal data is not being updated correctly after one of the operators but is being updated on .blend load?

Some things I've noticed that probably fall into this category of fixups:

That card may not be fully OpenGL 3.3 compliant according to its specs: https://www.geforce.com/hardware/desktop-gpus/geforce-gt-120/specifications

Duplicate of T56011 probably

Here's a gif showing the flicker in case a repro is hard to see -- happens on my 2 Win10 machines, 1 with nVidia Quadro and 1 with AMD fire pro

The spec sheet for that graphics card only lists OpenGL 2.1 (which is below the minimum that 2.8 requires which is 3.3): https://www.geforce.com/hardware/desktop-gpus/geforce-9500-gt/specifications

The option would be system wide, and called something like "Remember previous operator settings: True/False". You would Ctrl+B and confirm whatever you want. After that, each time you Ctrl+B you get the values that were confirmed prior. No additional button required, just Ctrl+b, Ctrl+b, Ctrl+b etc. etc. It's system wide since this would work with the Inset operator too, and probably others.

Yup, same crash with using the, very slow, opengl32.dll

I'm away from my laptop, however, I can reproduce the problem on my office desktop as well -- same crash using the vc14 builds. System is Win10, nVidia Quadro 600 this time.

Ok, I tried again, here's some more interesting information: