Closed deivid-rodriguez closed 7 years ago
Thanks @deivid-rodriguez!
I think it makes sense to do that. I think most of the Ruby community migrated from 1.9 to 2.x. New codebases will most likely not use 1.9.3, and the old ones can live with old versions of rainbow.
I never tried to use rainbow under Windows and I don't have Windows at hand at the moment to check things, but is there any (semi-)official information about the fact these extra gems are not needed on Windows for Ruby 2.x?
I have absolutely no idea, not a Windows user myself either. My only source of information here is the info that was present in the README and the version check that was being done in the extension.
In my repos I use appveyor when I want code tested on Windows. It could be an option to verify this.
I'm 100% convinced to drop Ruby 1.9.3 support anyway (it became EOL in February 2015).
Yeah, ruby 2.0 was also EOL'd last year and 2.1 will be EOL'd in February this year (I guess): https://www.ruby-lang.org/en/news/2016/02/24/support-plan-of-ruby-2-0-0-and-2-1/.
So I'd say "ancient" is becoming a better word than "old" to refer to Ruby 1.9.3... :)
I have absolutely no idea, not a Windows user myself either. My only source of information here is the info that was present in the README and the version check that was being done in the extension.
I have run rubocop on my windows machine one or two times. So if you tell me what I should do, I could at least do something basic like bundle and run rubocop with one branch of the gem and another and see if it works.
At least if that is of any help for you.
@NobodysNightmare I think confirming that RuboCop runs with colors without any of windows-pr
or win32console
gems installed might suffice.
@sickill I added an extra commit to remove usage of those gems.
@sickill I squashed the two commits into one because they were part of the same thing. I also added a sample appveyor.yml
. If you want to start testing the gem on Windows, I think it's enough to sign in and add the project: https://www.appveyor.com/docs/.
Let me know how you want to proceed and what else you need! :wink:
@sickill Hi! Not meaning to be annoying, but I am having trouble installing 2.1.1 and you mentioned in another issue that this was the trick to getting native extensions to build again. Any thoughts on the progress of this PR?
The real fix is to do gem update --system
. This PR is nice to get merged but not really necessary anymore.
+1 to dropping support for ancient 1.9.3
Hi! So apparently people are still having issues with this. @sickill Are you still up for dropping 1.9 support?
@deivid-rodriguez yes, let's do this. I'm not sure about appveyor config though. We could discuss appveyor inclusion in a separate PR maybe, and remove it from this changeset. What do you think?
Sure, I was just trying to minimize "fear to breakage" since none of us is a Windows user :)
I'll remove that from this PR tomorrow!
@deivid-rodriguez great. I'm open to discussion about that, but I just prefer to keep PRs/commits focused ;)
The idea of adding appveyor was to try to address this comment of yours without having to install Windows
I never tried to use rainbow under Windows and I don't have Windows at hand at the moment to check things, but is there any (semi-)official information about the fact these extra gems are not needed on Windows for Ruby 2.x?
So it seemed focused.
Anyways, PR splitted!
CI failing in Ruby 2.0... We could potentially drop that too, Ruby 2.1 was EOL'd some days ago: https://www.ruby-lang.org/en/news/2017/04/01/support-of-ruby-2-1-has-ended/.
Fixed CI and added one more cleanup (gem mime-types
is no longer needed in Gemfile
).
Oh man, I love dropping support for old Rubies, makes me feel so shiny and clean :D Good job!
I'm for dropping support for Ruby 2.0 too in rainbow 3.0 👍 Let's do this!
Does it make sense to first merge #58, release it as rainbow v2.2.2, and then merge this one as rainbow v3.0? It wouldn't be a lot of work to do it. On the other hand one can always(?) do gem update --system
to solve this... correct?
@sickill It would be very nice to be able to solve these issues in a v2.x release for folks who can't upgrade a major version easily. Major version bumps require coordinating lots of dependencies which can be a huge hassle (e.g. upgrading from json v1.7 to json v2.0 was a huge coordination effort between three or four dependencies and took a year or so). So a minor bump to alleviate some of these issues would certainly be nice if possible.
@sickill Your plan makes sense to me. Adding rake
as a dependency has been reported as something that helps alleviating the problem. And it also makes sense since the extension compilation depends on rake
so in v2 rake
is indeed a dependency.
Maybe @olleolleolle has any thoughts on this?
PR rebased and 2.0 support dropped!
@deivid-rodriguez thanks for your contribution! I guess I'll just release 3.0.0 now.
You are welcome, thanks for maintaining this gem! :)
Installing Windows specific dependencies through an extension seems to be causing a lot of installation trouble. It is indeed the only way I know of achieving that, but it's not working well at the moment. In my case, I get a different error from #44:
Since the extension is only used for the Windows + 1.9.3 combo, I'd say the simplest thing to do here is to just drop 1.9.3 compatibility.
This should happen at some point, and it's been already unofficially dropped a while ago.