laurence-myers

SemVer is a social construct, not a contract. It's nice when it applies, but you cannot rely on other developers to adhere to it.

One man's bugfix is another man's breaking change. If product A implements a workaround for a bug in product B, but the bug gets fixed in a patch version, it could break product A's code, so it becomes a breaking change. The only way to anticipate these changes is reading the change logs/release notes, and thorough automated regression testing. (Obviously unfeasible for every dependency.)

Maybe versions should be a single number, like a build number. It just gets tricky when you have multiple versions out there, each requiring patches.

I think you can achieve this by creating a "Scope" and filtering to it in the Project view.

They go hand in hand. If you write tests, but they're not run after each dev commits changes, you're not testing those changes for regressions. If you have CI without tests, what is the CI going to do? It could still be used for packaging executables/distributions, and possibly orchestrating deployments, but it sounds like that's not your goal.

Save yourself some grief and use a service like CircleCI, it provides isolated (Docker) environments that are spun up per test run. It supports many languages and background services (like databases).

As for writing tests, you would be best to start writing them at a "system boundary". This might take the form of sending HTTP requests to your endpoints and parsing the response.