refactor: rebase with next-major branch

[magicmatatjahu]

Description

Rebase (or merge 😅) with next-major branch to enable contributions with API for new major spec.

I'm wondering if my approach in this PR is good, or should we remove the next-major-spec and create it based on next-major, or differently? Any suggestions on how to do it right?

In next PR I will add all needed code for models for next spec to start contributions.

cc @smoya @jonaslagoni @fmvilas @derberg

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
No Duplication information

[smoya]

I'm wondering if my approach in this PR is good, or should we remove the next-major-spec and create it based on next-major, or differently? Any suggestions on how to do it right?

I think the simplest solution is to reset the next-major-spec branch to next-major HEAD so both branches are identical. From there will diverge.

[magicmatatjahu]

@smoya

I think the simplest solution is to reset the next-major-spec branch to next-major HEAD so both branches are identical. From there will diverge.

But after merging next-major to the master we will have still commits from next-major in the next-major-spec, so I'm afraid about bigger problems with rebase than with given PR. Any thoughts?

[smoya]

@smoya

I think the simplest solution is to reset the next-major-spec branch to next-major HEAD so both branches are identical. From there will diverge.

But after merging next-major to the master we will have still commits from next-major in the next-major-spec, so I'm afraid about bigger problems with rebase than with given PR. Any thoughts?

Totally the opposite, you won't have any conflict until the commit today HEAD of next-major points to. After that commit, you could have conflicts but you can't avoid that in any way.

[magicmatatjahu]

Close in favour of #637