It all depends on the overall software development process. Configuration management and how a new version comes to be cannot be defined without knowing about the overall process.
There is the "agile" faction who would opt for a "always working first commit area". They would run automated build and test facilities constantly against that area and try to have a working system "at all times".
They would see the (master) -> (release) with maybe 1,2 intermediate steps organization as beneficial.
Then there is the more "classic" faction, which has a process driven by planning and planned integration steps towards milestones, where a "unit of work" release is a planned activity with requirements such as "only release when it is (unit) tested and supposed to fit to the next planned milestone". There, the planning comprises the versioning of "units of work" and typically they go to lengths to define how the next planned product release is supposed to look like in terms of features and fixes. For the sake of planning, they want to know that what a developer releases is "proper" and a conscious act of committing a unit of work.
That classic approach does not mean necessarily that there are longer times where there is no complete product build is available.
So the "classic" workflow would be: (dev) -> (unit) -> (integration) -> (test/qa) -> (production).
The role of the integrator is to "accept/buy" released units or reject them if they do not fit the needs of the next upcoming release.
It is, on a side note also possible to mix those 2 basic approaches in opportune ways.
From my experience (which was mostly in the area of using the "classic" approach), the "classic" approach worked decently well in projects from about 4-50 people in a team.