hohwille
commented
1 year ago Another very important argument for this story is what I realized after the release: If nobody in the team is aware of the new devonfw-ide release and ide-urls, edition changes, etc. then nothing will change (e.g. in the settings git repo). However, if a new person joins the team he will download the latest devonfw-ide and as this is the first installation no migration script will run. However, the settings git repo will still contain the old edition variables that would have been incompatible with the new release causing confusing errors. Hence, it is very good that I fixed this on the last mile...
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 dodevon 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: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).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.