Bug: Specifying a position with add_new_at: :top fails to insert at that position #220
Conversation
I’ve changed the tests to cope with this change in behaviour. This will potentially be a breaking change for people, though why someone would be taking advantage of the ‘feature’ whereby specifying a `position` on `add_new_at: :top` is ignored, is beyond me :)
|
Hi fella's. I'd like some feedback on this one as it breaks currently tested behaviour, though the existing behaviour is weird to begin with. Let me know if you need any more details. I suppose we'd bump the minor version if we released this? |
|
|
|
Yes, they seem to be intermittent? Or perhaps I'm thinking of another time. Thanks for taking a look. I don't use Rubinius so I'm not sure what's going on :) |
|
Perhaps we're testing against an old version of |
|
Just closed and reopened this one to see if the |
|
Hi @swanandp, Rubinius seems to be a bit flaky with travis-ci. The latest test run just failed outright on installing the gems. Should we look at dropping support for that particular ruby franchise? It's certainly causing uncertainty in development. |
|
Scratch that, it seems it's to do with the extra gems we're specifying for |
|
This is super frustrating. One pass and one failure, same code! :) And nothing major changed between versions :( Do we just go ahead and merge this @swanandp, and put it down to a bad travis stack? |
|
This looks like an interesting problem to tack down, but let's go ahead an On Tue, Aug 23, 2016 at 3:01 AM, Brendon Muir [email protected]
|
|
Yea, I've emailed the travis support team. See the Rails 4.1 test passed in the last run, then the 5.0 test failed! I think it's some instability on their end honestly. I'll merge this and do an 0.8.0 release. |
|
0.8.0 has been released and includes this change. |
I've created a test that confirms the bug. Now I guess we figure out how to fix it.