Roll-back #1301 and #1289 to allow 0.7.0 release. #1305
Conversation
|
FYI, I'm going to be rebasing as I fix things to keep this to a single commit. |
non
force-pushed
the
topic/revert-1301-1289
branch
from
6618e0b
to
f05c7d9
Compare
non
force-pushed
the
topic/revert-1301-1289
branch
from
f05c7d9
to
87043e4
Compare
|
👍 |
|
Looks like there's |
non
force-pushed
the
topic/revert-1301-1289
branch
from
c2ac62f
to
aac4fe2
Compare
Due to a communications error we merged some PRs which we had been planning to keep out of master until after 0.7.0. Since one of them (typelevel#1289) was large and long-running, it was difficult to undo this merge in an automated way. This commit represents the following: 1. Downloaded patches for PRs 1301 and 1289 from Github 2. Tried to reverse-apply them (-R) 3. Fixed rejections/failures manually 4. Got code compiling and tests passing The code is now different than it was before the PRs were merged, but things *seem* to be in a reasonable state. I'm keeping all these changes in one commit so that it will be easier to "reverse" this once 0.7.0 is relaesed.
non
force-pushed
the
topic/revert-1301-1289
branch
from
aac4fe2
to
e137bda
Compare
|
I'm actually a little confused here. 0.6.1 didn't have FlatMapRec. So changing it to take Either rather than Xor is not going to break anyone. The other change is to make Either more usable, and that also sounds nice. Why don't we want the Either based tailRecM now rather than introduce it just to change the signature in the next release? |
|
@johnynek Due to the way things were merged it ended up being easier to do it this way. I don't have a principled argument here but I also don't really want to try to change that part. |
|
@non I think @johnynek is pointing out that the only changes that need to be reverted are those which affect existing APIs in 0.6.1. For instance, |
|
So what do we n d to rollback if not the Either stuff? I'm a little nervous about the API churn and the deep stack of libraries I have been using that use Cats. If breakage is painful, it is going to lock me on 0.6.1 for a while. |
|
Yes, @adelbertc, that is my point exactly. |
|
Alright, as-per discussions on Gitter it seems like we've decided to hold off doing a full-scale revert and instead just revert the existing API changes (to minimize 0.6.1 -> 0.7.0 breakage). This will make the future 0.7.x -> 0.8.0 upgrade path less painful. @adelbertc agreed to take point on this. In the meantime, please don't merge this PR unless things change. |
Current coverage is 90.71% (diff: 97.29%)@@ master #1305 diff @@
==========================================
Files 235 234 -1
Lines 3607 3383 -224
Methods 3549 3325 -224
Messages 0 0
Branches 54 56 +2
==========================================
- Hits 3268 3069 -199
+ Misses 339 314 -25
Partials 0 0
|
|
Fixed in #1306 closing this PR. |
Due to a communications error we merged some PRs which we had been
planning to keep out of master until after 0.7.0. Since one of them
(#1289) was large and long-running, it was difficult to undo this
merge in an automated way.
This commit represents the following:
The code is now different than it was before the PRs were merged,
but things seem to be in a reasonable state. I'm keeping all these
changes in one commit so that it will be easier to "reverse" this
once 0.7.0 is relaesed.