You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When we publish a new release, our users can install it to existing devonfw-ide installations via devon ide update scripts.
Sometimes we do some structural changes, here is a brief history with just some examples:
we have changed the eclipse configuration structure in settings/eclipse/workspace
we have moved the eclipse plugin configuration from hard-coded settings to settings/eclipse/plugins
we are planning to migrate from ide-mirrors to ide-urls
Due to such changes we sometimes "pollute" our scripts/commandlets with legacy handling code (see #904 or see ide commandlet with blocks of cp and mv commands, etc.).
Instead, we should create a bash script scripts/migration where we can place logic that would be executed automatically by devon ide update scripts but at the end on the new release.
To avoid mistakes and make things simple for developers, I would propose that the migration script gets called with the previous version of devonfw-ide that just has been updated. We create a subfolder scripts/migrations where we can create scripts for specific migrations named by the source version. So e.g. when we have version 2022.11.001 installed and call devon ide update scripts then migrate script would find all scripts in migrations subfolder that are named by a version greater or equal to 2022.11.001 so he may find migrations/2022.12.001 and execute it. In case someone knows flyway or liquibase this is the same pattern that we are trying to implement here...
We can still discuss if we need to track the version of devonfw-ide itself for reliability (e.g. in .devon.software.version file in DEVON_IDE_HOME).
The text was updated successfully, but these errors were encountered:
When we publish a new release, our users can install it to existing devonfw-ide installations via
devon ide update scripts
.Sometimes we do some structural changes, here is a brief history with just some examples:
settings/eclipse/workspace
settings/eclipse/plugins
ide-mirrors
toide-urls
Due to such changes we sometimes "pollute" our scripts/commandlets with legacy handling code (see #904 or see
ide
commandlet with blocks ofcp
andmv
commands, etc.).Instead, we should create a
bash
scriptscripts/migration
where we can place logic that would be executed automatically bydevon ide update scripts
but at the end on the new release.To avoid mistakes and make things simple for developers, I would propose that the
migration
script gets called with the previous version of devonfw-ide that just has been updated. We create a subfolderscripts/migrations
where we can create scripts for specific migrations named by the source version. So e.g. when we have version2022.11.001
installed and calldevon ide update scripts
thenmigrate
script would find all scripts inmigrations
subfolder that are named by a version greater or equal to2022.11.001
so he may findmigrations/2022.12.001
and execute it. In case someone knows flyway or liquibase this is the same pattern that we are trying to implement here...We can still discuss if we need to track the version of devonfw-ide itself for reliability (e.g. in
.devon.software.version
file inDEVON_IDE_HOME
).The text was updated successfully, but these errors were encountered: