What is the technical term for when the developer decides that a version has had enough and moves all the teams to the next version?

A revision gets "tagged" or "labeled".

A developer might tag change #152327 as "Alpha Candidate 1", then tag #153198 as "Alpha Candidate 2", and so on.

The version control user can pull down that change number and get all the files as they existed at that point.

Note that this is a good reason to store all the non-code assets in version control. You probably want not just the code as of that moment, but also the same images, videos, sounds, text strings, and other data as well. You might also want to ensure you have the build scripts, tool chains, compilers, libraries, and other items used to build the program in version control, as those can also be difficult to track down.

What is the technical term for when the developer decides that a version has had enough and moves all the teams to the next version? (be it alpha, beta, RC, or published versions or "subversions" )

I would call "publishing" or "releasing". What that exactly means depends on the work setup.

Tagging or labeling, as frob explained above, tags a single revision as "this is the one". While the VCS can store names associated with a revision, it has no special semantics to them, you define that in your project. In larger teams, a single tag isn't enough. Some programmers must work further on remaining things for the next release, while eg QA runs tests, and the program needs final packaging files, removal of development setup, test code, etc. Your "this is it" is thus not a single revision, it's a line of development (aimed to publish said version). Such a line is called a "branch" or more specifically "release branch". The technical term in VCS is "branching" for this operation.

Lines of development are useful at lots of places. If you release a sequence of versions (3.3.0, 3.3.1, 3.3.2, etc) you could see 3.3.x as a line of development, and each version also as a line of development (allowing eg 3.3.1.1).

Several lines of development are more often seen in adding features and fixing bugs. Eg github does this. When I want to add a new feature to a project, I clone the project (make a new branch for myself for the feature), hack (make a sequence of patches implementing the feature), and offer it back to the main development (merging my feature branch back to the "master") with a PR, with code review of one of the project committers and/or automagic build attached to it.

One way to organize branches is eg https://nvie.com/posts/a-successful-git-branching-model although I think it's heavy at the "release" side (anything right of "develop"). Also, I would have used "master" for development instead of "develop" (less risk in getting people confused). Last but not least, there is nothing git-specific here, you can do this in any VCS.

For a discussion on using branchy development (stuff left of "develop"), you could read about UQDS, a development method for small teams (https://twistedmatrix.com/trac/wiki/UltimateQualityDevelopmentSystem), where issue tracker, feature/bugfix branches, and code review are nicely integrated. I have worked in this system for a long time. It really works.

All this and more is possible. VCS typically doesn't make any decision here, you're free to do whatever you see fit. This is also the biggest problem, you have to decide what you see fit, but how do you know if you never worked with this stuff?

I would say start simple. Don't add branchy development because you can, only because you need it. Each branch that you make generally also needs to be merged again, so branching isn't entirely free in development time. On the other hand, having a branch to do a single thing is good, it puts focus on what you're doing, and it makes it easier to later retrieve what you did (or did not do), by browsing VCS history.

Can I assume that this should usually be determined by coding needs?

Depends on project policy. Some project make a list of features that should be in the next version (often called milestones in issue trackers). Others do it purely based on time, or "when there are enough new things".

The VCS doesn't care what you do, a release tag or branch is not different from any other tag or branch.

I am assuming that all the VC let the teammates know that they are working on the next version automatically.

No, the VCS only handles versions and branches, and that's it. You need a form of team communication around it to sort out the eg who is doing what (can be the issue tracker for a large part), but also to avoid conflicts. (If one developer makes big changes in one area of the program, it's useless to have another developer also work there on some different issue, as they just run into each other, leading to merge conflicts etc.) In general this needs knowledge of the software structure, and wise people decisions, not something a VCS can do.

In general, I believe developers talking to each other is essential. Different people have different knowledge and insights, and can help each other with working out a design problem. VCS troubles is a margin topic compared to that :)

Even if you don't use a VCS and an issue tracker, you definitely want the team to talk to each other as much and as open as possible.