You should decide at which level to engage the versioning mechanism in the content structure of a project.

Assume you have a project with many books. Obviously books have chapters, subchapters, and topics. If you deliver books to your users it is recommended to enable the 'new versioning' mechanism only for 'books'  and NOT for the books dependants (chapter, topic). How to enable the versioning is described in changing the classes. So, you would need to change the 'Book' class under 'Project' class and if you are working with a common folder in stead of a project folder you need to change the 'Book' class under 'Folder' class.

Enabling the creation of separate new versions of a folder's dependants (chapter, topic) is possible, but it can become very confusing. Specially in a system where individual content objects are shared and when you start restoring versions.

Although it is possible, it is not recommended to create versions for the entire project, or for a folder at a high level in the project. The version's scope would be to wide in that case.

Basically, a good approach would be to start creating new versions at one specific point in your structure, for example the books. If required, this approach can be changed later.

It is easier to use the versioning on request method. In this case you decide when to create a new version and you keep control over the number of versions. The other method,  creating new versions on publish is to fix every change on publish into a version (perhaps required for legal content). And in that case the number of versions will increase significantly.

Also, you should ask yourself if it is required that your users can revert to previous versions. And how far in the past they need to go. Or do the authors just want to keep a couple of previous versions aside, to have a fall back or to see how things were in the past. The answer to these questions determine your versioning limits.

In many cases people use the versioning on request method. They create a new version of the content every 6 months. And they delete the oldest version after creating a new one. So, basically they just keep two versions during the year.

But still you decide how to version your content. If you think that the chapters are the 'point of versioning' then enable it for 'Chapter' under 'Book'. But it is strongly recommended not to use a mixed versioning setup, you will loose control.

Perhaps HelpServer's versioning concept can look a bit complex but it is designed to consume as less resources as possible.

Assume you have a book with thousands of topics and you have created a version V1 for the book. If you then would change and publish just one single topic and then version the entire book in a new version V2 then only a new content instance will be created for that changed topic. The rest of the content objects just gets an extra version name. So, a 'version' is in fact a reference to a data object. If that data object is not changed in a next new version, then the new version name just points to the same object.

So, there is little overhead in creating a new version from a book or any kind of folder if the book or folder hasn't changed much.