Sinatra has been slow to release a version compatible with AR 5,
so having a dev. dependency on sinatra has been painful. This is the
main reason for the move, but there are the other, usual reasons:
- Better organization of github issues
- Independent development. The sinatra integration can target older
versions of PT, for example.
- Rails users don't want sinatra integration in their apps, even if
it's basically inactive.
And, of course, there is the inevitable downside that sinatra integration
is now a second-class citizen. That's the trade-off with separate gems.
In https://github.com/airblade/paper_trail/pull/895, Sean asked:
> .. since it looks like the next version is planned to be 6.0.0, how would
> you feel about dropping support for Rails 3 in that version? It has
> reached end of life, meaning it no longer receives security patches. We
> don't recommend that gem authors continue to support it.
To which, I responded:
> We could continue maintaining PT 5 if we had to, so I think it's
> fine to drop support for rails 3 in PT 6. If Ben agrees, I'd be
> happy to make that change. I'll just update the gemspec and drop
> testing support, for starters. We can clean up the conditionals in
> the code over time.
This adds Rails master to CI as an allowed failure. While builds will
continue to pass regardless of this run, it makes it easier to keep an
eye on if changes need to be made for the upcoming version of Rails, as
well as automatically test shims to add compatibility
- ruby 2.3.1 (was 2.3.0)
- Update AR5 gemfile now that rails 5 is out
- Enable travis bundler cache. Hopefully this will speed up travis a bit.
https://docs.travis-ci.com/user/caching/
- set TargetRubyVersion: 1.9
We're seeing an issue with slow dependency resolution for
the AR3 gemfile, consistently taking 10 minutes on travis.
I am hoping that stricter version constraints will make
bundler's job easier.
If this doesn't improve the situation, we may have to try
debugging with `DEBUG_RESOLVER=1` turned on.
Jared Beck