Skip to content
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
merged 2 commits into from
Feb 5, 2020
Merged

LPS-107869 Update CKEditor to latest version (v4.13.1) #36

merged 2 commits into from
Feb 5, 2020

Conversation

markocikos
Copy link
Member

@julien A followup on #34, with standardized commit messages.

@julien julien merged commit 5459713 into liferay:master 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.
@wincent
Copy link
Contributor

wincent commented Feb 12, 2020

So this PR doesn't include the submodule update:

liferay_liferay-ckeditor

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.
@wincent wincent mentioned this pull request Feb 13, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants