spec
spec copied to clipboard
feat!: release for version 3.0.0 of the spec
This PR is created upfront to reflect on a daily basis what things are included in the release.
Also, the reason to create this PR a long time before the release is to enable automation (bot keeps upstream branches always up to date with master, see this action) that we have in place to regularly update the release branch with whatever is changed in the master branch. So nobody has to do it manually.
/au
Kudos, SonarCloud Quality Gate passed! 
0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells
No Coverage information
0.0% Duplication
I don't get why we are having those conflicts here. I expect these merges to apply without conflicts as there are no changes in this branch either.
I wonder why this PR is having conflicts. I was looking at the changes in #807 and they all seem pretty straightforward to auto-merge for git but for some reason, it's not doing it.
as there are no changes in this branch either
There are changes. In this branch, for instance, the examples are already "migrated" to version 3.0.0 and the spec already has the version number updated too. Still not enough to get this amount of conflicts IMO but worth mentioning.
as there are no changes in this branch either
There are changes. In this branch, for instance, the examples are already "migrated" to version 3.0.0 and the spec already has the version number updated too. Still not enough to get this amount of conflicts IMO but worth mentioning.
Oh, yeah I didn't notice. Thanks for mentioning it.
Kudos, SonarCloud Quality Gate passed! 
0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells
No Coverage information
0.0% Duplication
@jonaslagoni fyi there are many merge conflicts. Because of this, the bot cannot keep it up to date with master. This means workflows are not getting up to date, and this is why 3.0 release candidate was not now released after merging PR from @fmvilas
Let me have a look. I'm gonna rebase and cherry-pick to try to clean the history. Let's see if it works.
Alright, so I think I found the problem (or at least the PR that's causing the majority of them). #753 is changing a lot of files replacing 2.3.0 with 3.0.0. We do this on every minor release too so it's going to conflict every time we have a new release until we get 3.0.0. My suggestion is that we leave #753 out and we reapply it again when the time to release 3.0.0 arrives. Is everyone ok with this?
@jonaslagoni @derberg @dalelane
Kudos, SonarCloud Quality Gate passed! 
0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells
No Coverage information
0.0% Duplication
Kudos, SonarCloud Quality Gate passed! 
0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells
No Coverage information
0.0% Duplication
Kudos, SonarCloud Quality Gate passed! 
0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells
No Coverage information
0.0% Duplication
Kudos, SonarCloud Quality Gate passed! 
0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells
No Coverage information
0.0% Duplication
Because of this issue, we need to manually merge this PR if we want to keep mentions to the co-authors of this PR.
So please, when merging, add the following commit message description literally (with the two empty lines at the beginning as well):
Co-authored-by: Sergio Moya <[email protected]>
Co-authored-by: nickshoe <[email protected]>
Co-authored-by: Rishi <[email protected]>
Co-authored-by: Fran Méndez <[email protected]>
Co-authored-by: Heiko Henning <[email protected]>
Co-authored-by: Lukasz Gornicki <[email protected]>
Co-authored-by: samz <[email protected]>
Co-authored-by: Maciej Urbańczyk <[email protected]>
Co-authored-by: Vladimír Gorej <[email protected]>
:tada: This PR is included in version 3.0.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:
