-
Couldn't load subscription status.
- Fork 103
Description
With #971 we introduced migrations to avoid code handling legacy compatibility and with #1087 we implemented this for our changes of 2023.07.001 release.
While this works fine for changes that are only local to my devonfw-ide installation, whilst testing I figured some cases where it caused problems. That is for changes affected to the settings that are shared across a team. What if you have a large team and some people upgrade to 2023.07.001 while others did not (because they missed the info to upgrade or whatever). In such case the new team members will need the new settings (INTELLIJ_EDITION=ultimate) while the others will still need the old one (INTELLIJ_EDITION=U). So as a result the people with the old devonfw-ide installed release will be switched from ultimate to community edition in that case if they do devon ide update. Teams could also use #999 to tell the others to update. However, most teams will not study our entire CHANGELOG to be aware of such things.
Therefore, I would suggest to take action before we do the final release:
- We could add
DEVON_IDE_MIN_VERSION=2023.07.001to thesettings/devon.propetiesin our migration (if we hit an according change, e.g. an edition variable was changed inside settings). - We could simply add some legacy handling for the according old values for editions.
I am aware that I created story #971 to avoid such legacy code, but for KISS, I would simply go for the latter. Besides we will do a great cleanup with our Java migration anyhow.