refactor!: follow go semver

[julienrbrt]

Prepare Ignite v28.

Did the following:

find . -type f \
    -name '*.go' \
    -exec sed -i -e 's,github.com/ignite/cli,github.com/ignite/cli/v28,g' {} \;

and edited the go.mod.

I now need to check the github actions and documentation to be sure it points to the proper way of installing and using Ignite (apis).

[github-actions]

Visit the preview URL for this PR (updated for commit c4e9445):

https://igntservices-docs--pr3793-julien-v28-nyh6vomo.web.app

_{(expires Mon, 11 Dec 2023 20:34:42 GMT)}

_{🔥 via Firebase Hosting GitHub Action 🌎}

_{Sign: 95379efd94dd497aaa37c2d0354e6e2cafca5ec5}

[tbruyelle]

Sorry to come after the merge, but this change will cause a lot of merge conflicts, not to mention make the release process more tedious. What exactly is the benefit? Is there an intent behind this that I'm not aware of?

[julienrbrt]

Why would it cause merge conflicts?
For the current PRs for sure, but I don't think it will afterwards.

We do need indeed such PR before each major release.

On the direction of moving to a major version, I'll defer to @ilgooz. However from I assure that it will make Ignite APIs easier to use.

[tbruyelle]

Why would it cause merge conflicts?

Every time there is a new release and some PRs exist but are not mergeable at the time of the release. And I think this will continue for the next releases.

For the next release, the ignite package path will change from v28 to v29, so in addition to conflicts, we'll have to be careful. For example, an existing PR might inadvertently keep some v28 imports. I always try to avoid this kind of thing you might forget :)

I was also worried about the templates, but I realize that at least the ignite dependency is no longer part of a scaffolded chain. So far, so good.

[julienrbrt]

Yeah, personally I am advocating the use of release branches, this may make the separation of concern and conflict limitation.
Like release/v28.x.x contains v28.x.x., then when we release, we push main to release/v28.x.x and already update main to v29.
Then we can backport anything for v28.x.x to release/v29.x.x and aren't limited to pushing breaking changes to main.

Right now, the flow is not working anymore when you want to push breaking changes to main (as releases are tagged there, and we follow go semver).

However, I know Ilker has other thoughts on that and would prefer v29.x.x feature branch (I guess it is a sort of development branch) instead with PRs targeting that branch instead, so we can keep tagging from main. The drawback is, once v29 is released we cannot maintain v28 anymore.

Whichever we pick, we do need to change the process anyway.

[tbruyelle]

Yeah, personally I am advocating the use of release branches, this may make the separation of concern and conflict limitation.

💯