In principle, we should avoid composite ID. I think there is a exception case: history table should apply composite ID.

For example, tOrder has a single PK: orderID. tOrderHistory has all tOrder's columns and one version column.

Everytime user update a record in tOrder, the old data will be inserted into tOrderHistory.

Should I add one more PK column to tOrderHistory, or just make a composite PK (orderID, version)?

I can not find any value of one more PK column for tOrderHistory. I always search tOrderHistory via orderID and version.
So I think composite ID is better than single ID in this case.

Am I correct?

The answer is "Yes and no". You could also implement this using a "ORDER_HISTORY_ID" which is a surrogate key and define constraints(reference, unique constraints) etc. on the table to ensure data integrity.
This would require an additional SQL in case you have the "generator" as "Sequence" to determine the "ORDER_HISTORY_ID".

In this case since the number of primary keys are just 2 you can go either way.