> Please suggest if my understanding is correct as per steps mentioned below.
Yes, your understanding is correct, but regarding my question it seems not to be complete.
Of course, v3.0 would not access feature id 1001, that's true.
What I tried to ask is: Let's assume that our license terms state (in fact, they do) that the latest license (v3.0) includes the rights to run an older software version by using that latest license (Feature ID 1003).
The user in my scenario still has v2.0 installed, but let's assume they purchased and activated v3.0. Consequently, when starting the software version v2.0, they should have the rights to use it, because the v3.0 license includes the rights to use v2.0.
You may ask why this is important: In our experience, many users don't like to be forced into an update. They may be used to be working with v2.0 and for some urgent work to be done, they can only be fast with the software they know by heart. An update may slow them down for their project. On the other hand, for our sales team it's best practice to write offers for the current software versions only (we have to avoid selling licenses for older versions, it makes pricing too complicated). That situation leads to the requirement, that older versions should run with latest licenses.
I'm aware that it would be possible to artificially create a downward compatibility like this, if older versions would also access the feature ID's of upcoming versions. Let's say v2.0 would be so smart to access 1002, if this doesn't work, it tries to access 1003, then 1004, then 1005. That would be a way to do it, but it seems more like a workaround or a hack than like professional version management.
I'm also aware, that nowadays, version management like this seems to become "old fashioned", because more and more licensors switch to subscription models. So maybe my question is not really on the modern side of monetarization. ;-)
Thanks for your response.
As you suggested, I will continue via mail, if needed.
Best regards,
Armin