The obvious answer is that the more bugs you batch up, the higher the chances the next build fails - this is why CI became a thing, small iterative changes are safer and lead to greater throughput

▲

dataflow 3 hours ago | parent | next [-]

CI doesn't mean doing all the tests all the time though. The expensive tests still wait until there's a major reason to run them. I had the same question as the parent and I still don't quite see why this can't work.

▲

aidenn0 3 hours ago | parent [-]

I didn't work on this project, but I've been involved with similar ones.

There is a process for getting a change into version control. Each change needs to have a (virtual) paper trail: motivation, risk analysis, sign-offs &c.

If you can't get something into VC quickly, you can't really do CI.

The obvious solution would be to have an integration branch that doesn't need the process to get in, do CI testing on that branch and then make the process for merging to the real branch.

I've never seen this done personally, but I have been told some places do it, and then you end up with "Change X, which got approved had a dependency on Change Y that didn't get approved and we didn't realize it until now because Change Y was put in the integration branch before Change X"

	▲	dataflow 2 hours ago \| parent [-]
		Well, approval is a different beast from passing tests. But also, that's not how I was imagining this. I was imagining maintaining separate branches on top of each release, only combining them (merge or rebase or whatever) when you have a good reason to. That keeps things independent and makes it so you can always cut a release with solely the critical fixes (and test them in isolation, etc.) whenever needed, letting you integrate the noncritical ones opportunistically.

▲

Manuel_D 3 hours ago | parent | prev [-]

True, but if each run of CI takes 6 weeks then you're going to vastly hamper development.