-
Notifications
You must be signed in to change notification settings - Fork 49
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
LPS-107869 Update CKEditor to latest version (v4.13.1) #36
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
julien
approved these changes
Feb 5, 2020
wincent
added a commit
that referenced
this pull request
Feb 12, 2020
This is exactly the same fix as applied in f3df483. The PR updating us to CKEditor v4.13.1: #36 did not include the submodule change. The explanation I gave back in f3df483 was this: Our submodule was pointing at un unpublished rev. The reason is that we have the submodule set to ignore changes (thanks to a2bd014), and so our `git add` command in `ck.sh` wasn't having any effect, and we ended up committing a reference to something that we only had in one of our local repos (probably a temporary "liferay" branch). This commit adds an `-f` to the `git add` invocation to prevent this from happening again, and forces the submodule to point at a published commit. I'm going to chalk this up to user error. The commit messages in the PR were obviously made by hand; eg. "patch: LPS-107869 Update CKEditor to 4.13.1" (3daf632). If they had been made using the `ck.sh` script, these two lines would have run: https://github.com/liferay/liferay-ckeditor/blob/6d6b972394f546f3bc3b8d3e6b3be97ba7295b3c/ck.sh#L265-L266 and the message would have been something like: Update ckeditor-dev to 4.13.1 411985373 (tag: 4.13.1) Updated language files.
So this PR doesn't include the submodule update: See how it is still pointing at the version from 9 months ago. Fix sent here: #38 |
wincent
added a commit
that referenced
this pull request
Feb 13, 2020
Created this initial one with a made-up-version number (v4.13.2), because I'm not actually about to cut a release: npx liferay-changelog-generator \ --regenerate \ --from=4.11.3-liferay.0 \ --version=v4.13.2 I then went in and edited the top (the fake release) and the bottom (the very first version, which needed to be done manually because there were no merge commits before the first version, and merge commits are what we use to populate the changelog). There is only one errant thing in the changelog, which is that the "same" change -- "LPS-107869 Update CKEditor to latest version (v4.13.1)" -- is featured in two versions. This is because we created and merged two PRs with identical titles: - #36 - #37 Rather than editing the changelog to distort what actually happened, we may as well just let the underlying messiness show through. Another gotcha here; we had a bad tag in the repo that caused the changelog generator from running: ``` tag v4.11.liferay.2 Tagger: Julien Castelain <[email protected]> Date: Tue May 28 15:02:28 2019 +0200 v4.11.4-liferay.2 commit 8da4564 (tag: v4.11.4-liferay.2) Author: Julien Castelain <[email protected]> Date: Tue May 28 14:57:19 2019 +0200 chore: Prepare for release 4.11.4-liferay.2 ``` This was causing Git to freak out with: ``` warning: tag 'v4.11.liferay.2' is really 'v4.11.4-liferay.2' here ``` The fix was to delete the v4.11.4-liferay.2 tag and recreate it. Now it looks like this: ``` tag v4.11.4-liferay.2 Tagger: Greg Hurrell <[email protected]> Date: Thu Feb 13 14:36:00 2020 +0100 v4.11.4-liferay.2 commit 8da4564 (tag: v4.11.4-liferay.2) Author: Julien Castelain <[email protected]> Date: Tue May 28 14:57:19 2019 +0200 chore: Prepare for release 4.11.4-liferay.2 ``` With that change made (and pushed to GitHub), the changelog generator worked. I expect subsequent updates should go smoothly, and because of #41 we are unlikely to have a bad tag created in the future.
wincent
added a commit
that referenced
this pull request
Feb 13, 2020
Created this initial one with a made-up-version number (v4.13.2), because I'm not actually about to cut a release: npx liferay-changelog-generator \ --regenerate \ --from=4.11.3-liferay.0 \ --version=v4.13.2 I then went in and edited the top (the fake release) and the bottom (the very first version, which needed to be done manually because there were no merge commits before the first version, and merge commits are what we use to populate the changelog). There is only one errant thing in the changelog, which is that the "same" change -- "LPS-107869 Update CKEditor to latest version (v4.13.1)" -- is featured in two versions. This is because we created and merged two PRs with identical titles: - #36 - #37 Rather than editing the changelog to distort what actually happened, we may as well just let the underlying messiness show through. Another gotcha here; we had a bad tag in the repo that caused the changelog generator from running: ``` tag v4.11.liferay.2 Tagger: Julien Castelain <[email protected]> Date: Tue May 28 15:02:28 2019 +0200 v4.11.4-liferay.2 commit 8da4564 (tag: v4.11.4-liferay.2) Author: Julien Castelain <[email protected]> Date: Tue May 28 14:57:19 2019 +0200 chore: Prepare for release 4.11.4-liferay.2 ``` This was causing Git to freak out with: ``` warning: tag 'v4.11.liferay.2' is really 'v4.11.4-liferay.2' here ``` The fix was to delete the v4.11.4-liferay.2 tag and recreate it. Now it looks like this: ``` tag v4.11.4-liferay.2 Tagger: Greg Hurrell <[email protected]> Date: Thu Feb 13 14:36:00 2020 +0100 v4.11.4-liferay.2 commit 8da4564 (tag: v4.11.4-liferay.2) Author: Julien Castelain <[email protected]> Date: Tue May 28 14:57:19 2019 +0200 chore: Prepare for release 4.11.4-liferay.2 ``` With that change made (and pushed to GitHub), the changelog generator worked. I expect subsequent updates should go smoothly, and because of #41 we are unlikely to have a bad tag created in the future.
Merged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
@julien A followup on #34, with standardized commit messages.