chore: release v14.1.0

[github-actions]

🤖 I have created a release beep boop

14.1.0

• FEAT: ensure lanes aren't resized when using space tool in Integrate Local Space Tool #1972
• DOCS: update translations for v14.0.0 by @bpmn-io-bot in docs: update translations for v14.0.0 #1948

---

This PR was generated with Release Please. See documentation.

[barmac]

The duplicated commit is due to my commit amendment on master + merge-to-develop action 🤡

[barmac]

OK duplicated commit message is fixed now.

[barmac]

Regarding this PR, I can see a couple of potential improvements:

• PR title should not contain the branch name master
• PR should be auto-assigned to modeling-dev
• We will need to be careful with commit messages to safe us some work. Notice how Closes https://github.com/bpmn-io/bpmn-js/issues/557 was placed in the deps commit of https://github.com/bpmn-io/bpmn-js/pull/1972/commits, and therefore ignored by the tool.

[nikku]

@barmac I do not understand this:

[...] was placed in the deps commit of https://github.com/bpmn-io/bpmn-js/pull/1972/commits, and therefore ignored by the tool.

For us we regularily upgrade our dependencies, fixing issues. How is this being ignored?

[nikku]

Do we plan to adjust our changelogs? I'd advocate not to do it (just yet).

[barmac]

We can:

1. (try to) Create a custom changelog template for release-please which resembles our current practice.
2. Accept the default release-please template for this and future updates.
3. Manually adjust the automatic changelog updates so that we stick to our current practice (until (1) is implemented).

I am OK with (2) as long as the default release-please template is good enough. I don't think our current changelog template is better than that.

[barmac]

Let me know what you think.

[nikku]

I like our existing template, because it is compact, and meaningful.

What you propose hides a major feature (cf. #557).

[nikku]

Also this clearly shows a gap in release-please. A new feature (local spacetool) may never be a patch.

[barmac]

A new feature (local spacetool) may never be a patch.

I totally agree with you. That's why we need to be extra careful with commit messages if we want automation. So it's no more "oh you labeled is as patch-releasable, but it's a feature in fact". Or we review automation result manually.

[barmac]

Perhaps it would make more sense to do sth like:

deps: update diagram-js to v12.2.0

feat: support local space tool

Closes #758

https://github.com/googleapis/release-please#what-if-my-pr-contains-multiple-fixes-or-features

[nikku]

Let's discuss this. If we want automation, then we want to be super strict about our commits. If we think we can be, then let's try it :).

[barmac]

Hmm custom changelog seems to be doable, but I couldn't find a way to do it in the github action:

https://github.com/googleapis/release-please/blob/main/docs/customizing.md#adding-additional-changelog-types

I did not dive deep though.

[barmac]

For us we regularily upgrade our dependencies, fixing issues. How is this being ignored?

I will check if we can easily include deps commits in the automatic changelog update.

[barmac]

For us we regularily upgrade our dependencies, fixing issues. How is this being ignored?

I will check if we can easily include deps commits in the automatic changelog update.

This is doable via https://github.com/google-github-actions/release-please-action#overriding-the-changelog-sections

[barmac]

I've created some adjustments and will push them to test.

[barmac]

OK it's applied in the PR. WDYT?

[barmac]

According to https://github.com/google-github-actions/release-please-action/issues/838, we cannot fully customize the changelog at the moment, if we stick to the release-please-action. I'd rather not switch to the CLI tool though. @nikku

[barmac]

We can also try out github way of doing release notes.

[barmac]

It looks like a step back to me ;) WDYT @nikku ?

[nikku]

Let's discuss with the team. I'm not a fan of overly verbose changelogs, and I also think a little bit of updating (cross-checking what we released) does not hurt.

The original ones the tool generated can trivially be grouped to fit our own CHANGELOG style, and we can learn how to write better commit messages (combine deps and feat).

But if I'm the only one in favor of keeping our changelogs, then I'm happy to adjust, too.

[nikku]

In terms of compactness I obviously prefer the github style. However it seems to swallow dependency bumps.

[github-actions]

🤖 Release is at https://github.com/bpmn-io/bpmn-js/releases/tag/v14.1.0 🌻