Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sinatra 2.0.0 alpha #1029

Closed
wants to merge 6 commits into from
Closed

Sinatra 2.0.0 alpha #1029

wants to merge 6 commits into from

Conversation

TrevorBramble
Copy link
Contributor

(Moved to PR #1033)

Here we go!

The Plan:

  • Drop support for Rubies earlier than 2.2 (MRI and equivalent implementations)
  • Change nothing else
  • Move 1.4 development to the 1.4.x branch, where releases will come from until 2.0 is fully released

Tasks:

  • Revise Travis matrix
  • Update gem version
  • Add Ruby version dependency to gemspec
  • Raise Rack version requirement to ~> 2.0, fix new incompatibilities
  • Remove overt conditional statements for dropped Rubies
  • Update English README to communicate new set of supported versions related notes
  • Coordinate translations for non-English READMEs
  • Sweep outstanding issues for 1.4.x changes before shunting to maintenance branch
  • ...figure out what else should be done...

TrevorBramble and others added 6 commits September 4, 2015 23:10
Drop Travis testing for Ruby versions lower than 2.2 (or equivalent).
Put the baseline at 2.2.0 because Ruby is now using SemVer and any 2.2.x
release should still be compatible.
@burningTyger
Copy link
Member

Great idea!
I'll take care of the German Readme as usual.

@TrevorBramble
Copy link
Contributor Author

@burningTyger Awesome, thanks!

@lgustafson
Copy link

Is there a reason to lock it to MRI 2.2 (or equivalent)? For example, RedHat/CentOS package ruby 2.0 but keep it updated with backported security patches. Any particular reason to prevent that user base from using Sinatra 2.0?

@TrevorBramble
Copy link
Contributor Author

@lgustafson There are two motivations for choosing 2.2. The first is that I want to match the baseline that Rack 2 will support, and the second, which also motivates the selection of 2.2 for Rack, is to make the supported versions as recent as possible because we can't drop support for them until retiring Sinatra 2. (Sinatra currently supports Rubies all the way back to 1.8.7.)

In my experience, Ruby applications delivered by package maintainers should be constrained by the Ruby versions likewise available in the (distro supported) package repository, but projects built and delivered outside of the official repositories should be unconcerned with system Ruby, given the popularity and stability of Ruby version management tools now.

@zzak
Copy link
Member

zzak commented Sep 7, 2015

I'm happy to start from here and begin work on 2.0, my only concern is once we branch it will make extra work for a 1.4 release. But without doing a full-sweep of the tickets, it's hard to tell how necessary another patchlevel or even minor release would be.

@kytrinyx
Copy link
Contributor

kytrinyx commented Sep 7, 2015

Any interest in doing a full sweep one of these days? If 3 or 4 of us get together in the Slack channel it shouldn't be too hard to get through (for most of the issues I have questions about context, precedent, etc, and don't want to make unilateral decisions just to get through them).

@TrevorBramble
Copy link
Contributor Author

@kytrinyx That pretty much requires @rkh's participation, right? I'm happy to help there but no more equipped than you are.

@kytrinyx
Copy link
Contributor

kytrinyx commented Sep 8, 2015

I don't think we'd need @rkh -- between you, myself, @zzak and @ashleygwilliams I think we could probably make reasonable decisions.

@lgustafson
Copy link

@TrevorBramble I understand the motivation to drop support for Rubies prior to 2.0.0 because they have been EOLed upstream. However, unless there is a particular feature of Ruby 2.2+ that Sinatra 2 would be leveraging I'd argue that it's better to be lenient in the gemspec and support Ruby 2.0.0 and above.

@TrevorBramble
Copy link
Contributor Author

Added new checklist items for sweeping outstanding 1.4.x issues, raising minimum Rack version.

@zzak
Copy link
Member

zzak commented Sep 10, 2015

I'd like to move this branch upstream so everyone with commit can push, and contributors can open PRs against this repo.

@TrevorBramble
Copy link
Contributor Author

@zzak Sounds good. Will do.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants