Aruba 0.7 can't be parsed on ruby 1.8.7 (and it generates a number of warnings)

[myronmarston]

Our RSpec travis builds are getting this for 1.8.7:

/home/travis/.rvm/rubies/ruby-1.8.7-p374/lib/ruby/site_ruby/1.8/rubygems/core_ext/kernel_require.rb:54:in `gem_original_require': /home/travis/build/rspec/bundle/ruby/1.8/gems/aruba-0.7.2/lib/aruba/api.rb:293: syntax error, unexpected tIDENTIFIER, expecting tAMPER or '&' (SyntaxError)
    def copy(*source, destination)
                                 ^
/home/travis/build/rspec/bundle/ruby/1.8/gems/aruba-0.7.2/lib/aruba/api.rb:956: dynamic constant assignment
    DEFAULT_TIMEOUT_SECONDS = 3
                             ^
/home/travis/build/rspec/bundle/ruby/1.8/gems/aruba-0.7.2/lib/aruba/api.rb:966: dynamic constant assignment
    DEFAULT_IO_WAIT_SECONDS = 0.1
                             ^
/home/travis/build/rspec/bundle/ruby/1.8/gems/aruba-0.7.2/lib/aruba/api.rb:976: dynamic constant assignment
    DEFAULT_ROOT_DIRECTORY = Dir.getwd
                            ^
/home/travis/build/rspec/bundle/ruby/1.8/gems/aruba-0.7.2/lib/aruba/api.rb:984: dynamic constant assignment
    FIXTURES_PATH_PREFIX = ?%
                          ^
/home/travis/build/rspec/bundle/ruby/1.8/gems/aruba-0.7.2/lib/aruba/api.rb:986: dynamic constant assignment
    DEFAULT_FIXTURES_DIRECTORIES = %w(
                                  ^
/home/travis/build/rspec/bundle/ruby/1.8/gems/aruba-0.7.2/lib/aruba/api.rb:1202: syntax error, unexpected kEND, expecting $end

Does Aruba 0.7 no longer support Ruby 1.8.7? Ideally support would have been dropped in a major version (e.g. 1.0). If you didn't intend to drop 1.8.7 support please get a patch release out with a fix ASAP and look into why your CI build process didn't catch this regression.

[maxmeyer]

@myronmarston I was not aware that we officially support 1.8.7 (see our old travis.yml). Will have a look into this on monday.

[myronmarston]

@myronmarston I was not aware that we officially support 1.8.7 (see our old travis.yml).

Maybe you don't support 1.8.7, but your History file mentions nothing about 1.8.7 support being dropped (and the mention of fixing 1.8.7 support in 0.4.9 implies it was supported).

As for your .travis.yml...the post-install message discussed in #278 implies that you do still support 1.9.3 but it's not in the .travis.yml file either.

Regardless, when you do decide to drop support for ruby versions, it helps users if you could do the following:

• Announce it in History.md.
• Set required_ruby_version in the gemspec (example from rspec-core).
• Do a major version bump of the gem since it's a breaking change. (That said, given that aruba is pre-1.0 its not clear to me what your versioning policy is).

Anyhow, I know that supporting 1.8.7 can be quite painful (RSpec supports it, and we feel that pain!) so it's totally reasonable to drop support for 1.8.7. It just surprised me to see aruba 0.7 suddenly not even being loadable on 1.8.7 after 0.6.2 worked fine on 1.8.7, given the lack of announcement. We'll keep rspec pinned to aruba 0.6.2 until RSpec 4 (which is the point we plan to drop 1.8.7 support).

[maxmeyer]

As for your .travis.yml...the post-install message discussed in #278 implies that you do still support 1.9.3 but it's not in the .travis.yml file either.

Removing it was the first step to deprecate it, though I must admit it was not a good idea to do so.

It just surprised me to see aruba 0.7 suddenly not even being loadable on 1.8.7 after 0.6.2 worked fine on 1.8.7,

The only reason for this was that I was not aware of that version requirement of yours. I just forgot, that I saw it in your gemspec. Sorry for the inconvenience. :-(

To clarify which versions we support and what our update policy is, I added a section in the aruba README. I leave the issue open for now, as 1.8.7 should be still supported. BTW I think aruba should still support 1.9.3. This is why I change the warning in the post install message.

[maxmeyer]

Just to give you an idea where I would like to move aruba:

1. Add configuration to aruba + polish API (0.8.0) - this will deprecate a lot and cleans up the api.
2. Improve documentation (0.9.0) - I added some new stuff as well in that PR
3. Replace all remaining assert_* and check_* methods through RSpec-matchers 0.10.0
4. Internal refactoring - command handling and announcing of information 0.11.0
5. Drop support for 1.8.7 and require cucumber 2.0 - 1.0.0

But this might be subject to change. ;-)

[myronmarston]

Removing it was the first step to deprecate it, though I must admit it was not a good idea to do so.

I agree that it doesn't seem like a good idea. In that state, it's still "officially supported" but the lack of a travis build means you have absolutely no idea if any of your changes have broken it.

Supporting old versions takes a a lot of effort (we deal with this in RSpec all the time...) and it's definitely not always worth the effort....but "officially supported but not tested on travis" seems a bit like wishful thinking.

If you want to drop support for old versions, that's fine; just be explicit about the fact that you are doing so. Don't claim you still support versions and stop testing against them.

[myronmarston]

The only reason for this was that I was not aware of that version requirement of yours. I just forgot, that I saw it in your gemspec.

I don't think you need to treat RSpec as a special case. The principles of SemVer (even if not followed to the letter) lay out some reasonable policies, the main one being "intentionally breaking changes go only in major releases" -- and dropping support for an old version certainly counts as an intentionally breaking change in my book.

[ghost]

0.8.0 was released.