Re: A quick follow-up release next week

On Sat, 25 May 2019, Daniel Gustafsson wrote:

> I favor option D (with the commit message clearly stating that the revert
> isn’t due to the commit in itself, but due to proess).

Thanks Ray and Daniel. I've now reverted the SASL authzid commits by merging
Ray's commit for it. We'll get them back in again after the 7.65.1 release.

> To take a play from another project I’m involved in, another way to deal
> with this would be to branch off every release with a standardized name

Yeah, that's one way. I have however tried to avoing creating branches for
release works mostly because we're a small team and I rather want us as a team
work on the next release, whichever it is, rather than to see us split up and
have some go merge in new features in the master branch while some others work
on fixing up a release in another branch.

But I also don't want to get stuck in a particular workflow just because
that's the way've done it before...

> Maybe we need some sort of automated.. matrix? .. of sorts which maps the
> options we have in CI and what we have in autobuilds, to be able to find
> blindspots?

That'd be really useful. I'm not sure how we would go ahead to create one
though! And also, some of the problems this time were because people do build
combinations with don't build in the CI builds plus and using TLS libraries
built with non-default build options which we don't test with either.

We also have to accept the fact that we offer waaaaay many more build
combinations than we can ever test so we need to be clever about it.

-- 
  / daniel.haxx.se | Get the best commercial curl support there is - from me
                   | Private help, bug fixes, support, ports, new features
                   | https://www.wolfssl.com/contact/

-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2019-05-25