Aaron Craelius

Sounds reasonable, but how would this work with major version releases given that the import path needs to change?

Yeah for minor and patch versions automation would be nice. Ideally this stays on a stable v1 for a while

I would note that the generate release notes feature in Github releases is pretty decent if we do need to do this manually.

It's a bit hard to retrieve the exact file and line number given the current way that gherkin is transformed into their internal pickle representation. Not impossible, but hard. What...

The existence of the core/app package definitely goes beyond the scope of what is needed to build a module IMHO and again raises questions for what is the intended scope...

So I'd like to propose the following: * for every newer go module including `core`, we should have a strict policy that **all exported types, functions, methods, fields, etc. should...

I believe the `revive` linter's `exported` rule can be used to check for doc comments

Was just looking at core/store yesterday. If core/store is store types for modules, then most of the stuff in there should be moved to some other package like core/server/store

Could someone give some concrete examples of what specifically is harder to test? i.e. what was someone doing before that they can't do now with a specific module example.

If GetProposals is part of the public API then it doesn't matter what implementation we use. If we removed it from the public API just because we thought it wasn't...