Refactor RegisterQueryServices -> RegisterServices

[aaronc]

ref: #7500

• refactors AppModule.RegisterQueryServices -> AppModule.RegisterServices
• adds the module.Configurator object for use in RegisterServices

---

Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.

• Targeted PR against correct branch (see CONTRIBUTING.md)
• Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
• Code follows the module structure standards.
• Wrote unit and integration tests
• Updated relevant documentation (docs/) or specification (x/<module>/spec/)
• Added relevant godoc comments.
• Added a relevant changelog entry to the Unreleased section in CHANGELOG.md
• Re-reviewed Files changed in the Github PR explorer
• Review Codecov Report in the comment section below once CI passes

[codecov]

Codecov Report

Merging #7518 into master will decrease coverage by 0.00%.
The diff coverage is 78.94%.

@@            Coverage Diff             @@
##           master    #7518      +/-   ##
==========================================
- Coverage   56.01%   56.01%   -0.01%     
==========================================
  Files         592      593       +1     
  Lines       37244    37246       +2     
==========================================
+ Hits        20864    20865       +1     
- Misses      14262    14263       +1     
  Partials     2118     2118              

[aaronc]

@clevinson @amaurymartiny how am I supposed to write a CHANGELOG entry for this? The CHANGELOG on master still has all the 0.40 stuff under unreleased. I'm general I'm a bit concerned of this strategy of divergent branches. I think it is smart to merge release branches back into master at regular intervals to deal with stuff like this.

[alexanderbez]

ACK

[amaury1093]

Approved.

I think it is smart to merge release branches back into master at regular intervals to deal with stuff like this.

Yes, I believe that's the plan once rc0 is out.

[alexanderbez]

Really? Release branches are not merged back into master/main unless we've changed our release workflow (i.e. we're no longer using trunk-based development).

[aaronc]

Really? Release branches are not merged back into master/main unless we've changed our release workflow (i.e. we're no longer using trunk-based development).

Well if we're not going to merge stuff back in then we'll end up with divergences like we do now. I'm not sure why we don't have the CHANGELOG updates on master.

[alexanderbez]

Everything goes into master/main. Backports are cherry-picked into long-living branches, which releases are cut from.

[aaronc]

This was merged directly into v0.40.x: #7437 which is why the CHANGELOG on master is now out of date. That should have been on master is that right @alexanderbez ?

[alexanderbez]

Yes @aaronc. Also why against v0.40.x and not backport/v0.40.x? Or are they the same?

[amaury1093]

Everything goes into master/main. Backports are cherry-picked into long-living branches, which releases are cut from.

The argument against this was that the CHANGELOG on master would show v0.40-rc0 for ~a couple days, which can be confusing, esp that so many people are waiting on the release.

Also why against v0.40.x and not backport/v0.40.x? Or are they the same?

There's no backport/v0.40.x branch.

[alexanderbez]

The argument against this was that the CHANGELOG on master would show v0.40-rc0 for ~a couple days, which can be confusing, esp that so many people are waiting on the release.

CHANGELOG on the main branch should only reflect 0.40 once 0.40 is released. IDK why we have an RC section on the main branch. We've never done this before.

There's no backport/v0.40.x branch.

We need to ;-) (unless this is the intention of the v0.40.x branch.

[aaronc]

@clevinson @amaurymartiny what's the plan for updating the CHANGELOG on master so we can add entries for this PR and other new stuff?

[clevinson]

@aaronc @alexanderbez

I think it's best to follow what tendermint has been doing, have changelog entries for the individual RC's, and then we can consolidate them into one changelog section once the actual release is published.

Here's a PR for getting master back up to date- #7528

All PRs on master should just have changelogs go into the unreleased section, this should also make it easier for us to cherrypick from that into subsequent RC's.

[clevinson]

@aaronc Sorry to have missed the boat on this- i was not working yesterday, and should have taken care of updating changelog on master on Friday probably. Can you create a changelog entry for this in a seperate PR into master?

[alexanderbez]

I suppose having RC changelogs added to the main branch is fine so long as we tidy it once we do a final release.

[fedekunze]

This PR is missing an api breaking changelog entry