Update to 2.0.0

[ocefpaf]

No changelog.

[conda-forge-linter]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

[jakirkham]

Do you know what API breaks occur in 2.x? Are they included in the Python module unittest.mock somehow?

[ocefpaf]

Do you know what API breaks occur in 2.x?

Nope.

Are they included in the Python module unittest.mock somehow?

It should.

[jakirkham]

We should really understand this before updating is my feeling as it will affect whether we need to make this a multi-branch feedstock or not.

[ocefpaf]

We should really understand this before updating is my feeling as it will affect whether we need to make this a multi-branch feedstock or not.

That is up to you as the maintainer. I proposing the update because I have a request from collaborators in another project for mock 2.0. I don't really use it.

Let me know you decision and I will apply it here.

[jakirkham]

Really, I just want more information first before updating to 2.x. So have opened this issue ( testing-cabal/mock#358 ).

The re-rendering changes are fine and I would happily accept them in another PR. Looks like that would be easy to do as you made them a separate commit.

[ocefpaf]

I will ask the folks who requested the update. Right now this is priority zero to me. (There are plenty more updates that I need to get done...)

[jakirkham]

AFAICT the only breaking change is dropping Python 3.2 support. That doesn't seem to be a crisis for us so I will merge this. Thanks @ocefpaf.

[pelson]

We should really understand this before updating is my feeling as it will affect whether we need to make this a multi-branch feedstock or not.

Worth noting: It is always easy to go back and make a maintenance branch even after merging if the requirement arises (i.e. if there is another 1.x release).

[ocefpaf]

Worth noting: It is always easy to go back and make a maintenance branch even after merging if the requirement arises (i.e. if there is another 1.x release).

Agreed. Updating versions should be normal and branch to create maintenance version the exception and not the other way around.

[jakirkham]

I'm a little concerned about playing lose with versions given our recent problems. I don't know of anyone that pins mock. Given 2.x was very recent and mock is basically part of the Python standard library at this point, I was a bit more nervous about this change.

So, apologies, but I don't agree and am quite fine taking this slow. Keep in mind slow here was less than a day. 😉

[ocefpaf]

So, apologies, but I don't agree and am quite fine taking this slow.

I am not asking for hastiness. I am more than fine with taking things slow! I am talking about standard procedures. I don't think we should be afraid the merge a new version all the time.

[jakirkham]

I don't think we should be afraid the merge a new version all the time.

So, this lack of fear has caused us some very serious issues in recent memory that only now have been mostly resolved. The lesson should be we need to be a bit more cautious on this point.

[ocefpaf]

So, this lack of fear has caused us some very serious issues in recent memory that only now have been mostly resolved. The lesson should be we need to be a bit more cautious on this point.

I had that fear when we updated version of hdf5. That broke all of my stack due to the libnetcdf and I had to bite the bullet and fix it. I still think that updating is the way forward and I don't think breakages will be a norm.

[jakirkham]

If we can figure out some sort of automated pinning mechanism, I would be less nervous about updating. We have something that is close, but I'm a little unclear on what has or has not been done on this front.

[pelson]

The lesson should be we need to be a bit more cautious on this point.

I wholeheartedly want to discourage you from this approach. It will be very easy to cripple ourselves from moving forwards if we have that mentality. I don't want to play fast and loose, but I also don't want us to be so cautious that we are afraid of making new released software available. Cautious or not, we will break software from time to time - rather than minimise the frequency of breakages I want us to minimise the downtime from breakages. I argue that the two approaches are very different:

If we try to minimise breakages:

• we will have a tendency for cautious change
• have more of a lag between tag and available on conda-forge
• have to enforce caution onto all feedstocks, not just the ones we are maintainers of
• we will be less practised at fixing the breakages, and so have a longer total downtime

That doesn't mean we shouldn't do our homework before merging things (as you have done here @jakirkham) - it is a perfectly reasonable thing to say "hold fire a few days, we need to update all of our other packages which depend on this otherwise they will break" if we know that will be the situation before merging. Sometimes though, things will bite us that we weren't expecting, and we need to make sure we are nimble enough to address them (not having me as a bus factor will help with that).