Yeah, this part is not documented at all, I had now also problems with it, so here is how I solved it:
When you want to migrate a content that has revisions, you need to migrate the first version with the
entity:node plugin, then you migrate the next versions with the
entity_revision:node. You don't do anything else, just change the destination plugin and when you migrate the revisions, you set the nid value to the first version of the node. So you keep the body and the file and other fields, you just add the nid field, so the revision plugin will know where to put the content. That's it at least from the yml part.
From the source, you have two one for the node plugin where you list only the first version of your content that you want to migrate and one for the revisions where you list everything EXCEPT the first version also, you have a new column which contains the first version's ID for every revision's it's own.
If you migrate the current publish one into the node table, and you migrate the rest into the revision, the IDs, the order of the revision and some other things will be messed up. At least my case was that.
By code (not 100% complette, just main parts):
#other fields except nid.
Query for the source plugin (id = my_node):
SELECT id, title, body FROM content WHERE version = 1
id is the only id.
Query for the source plugin (id = my_node_revision):
SELECT first_ver.id AS first_version, c.id, c.title, c.body FROM content c
INNER JOIN (
SELECT * FROM content c
WHERE version = 1
) first_ver ON c.resourceId = first_ver.resourceId AND c.articleId = first_ver.articleId
WHERE c.version <> 1
id is the only id.
The above example will give new id's for the content.
EDIT: note that the example in this answer is a migration from confluence database into drupal, so therefore slightly different than a normal drupal-drupal migration. Also, if you look in the entity_revision:node plugin, which is located here:
core/modules/migrate/src/Plugin/migrate/destination/EntityRevision.php you will notice that you have two ways of doing this.
A) Providing revision id.
B) Not providing revision id.
When you don't provide the revision ID, then as you add new revisions, it will always make the latest added revision the latest content version. (the example yml and source are like this above)
When you provide a revision ID, then you first need to add the current version into the node table, then add all the revisions and provide the revision ID, in that case, it won't make the last added revision as the latest content version.