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
This is of course doomed to fail when simultaneously releasing say 8.3.42 and 9.0.24 because the commit will be on each branch and when upmerging there will be a conflict. Those conflicts must be solved completely manually. Being lazy and always accepting ours for all package.json lead to missed dependency changes in the past when upmerging.
So i like to question the why. For composer.json we dont do this as well.
There was a reason for this in the past when we still manually wrote a version number into the javascript files so it would be visible in the Neos Ui, but this was refactored in the esbuild change.
Now the commit is obsolete and we can remove it.
The text was updated successfully, but these errors were encountered:
Currently up-merging the Ui is a PITA.
This is because after release, each branch will get pushed a new commit bumping the
version
field in EACH package.json:42ff732#diff-7ae45ad102eab3b6d7e7896acd08c427a9b25b346470d7bc6507b6481575d519
This is of course doomed to fail when simultaneously releasing say 8.3.42 and 9.0.24 because the commit will be on each branch and when upmerging there will be a conflict. Those conflicts must be solved completely manually. Being lazy and always accepting ours for all package.json lead to missed dependency changes in the past when upmerging.
So i like to question the why. For composer.json we dont do this as well.
There was a reason for this in the past when we still manually wrote a version number into the javascript files so it would be visible in the Neos Ui, but this was refactored in the esbuild change.
Now the commit is obsolete and we can remove it.
The text was updated successfully, but these errors were encountered: