The stopping, @ioquatix had some ideas about that, adding a wrapper around stop, that each adapter could implement, and Falcon implement, too, in a way which dodges the issue you mentioned.

Yeah having a wrapper would be a big improvement from the current implementation.

We will try to address this root interface issue in Rack itself. The Rack::Handler does not have a well defined interface. The server that gets yielded from Rack::Handler::(ServerClass).run isn't well defined and there wasn't an expectation that it has as #stop method or any consistent interface at all. It makes sense to me that this is better defined, but I'm not sure this ultimately belongs to "Rack the interface" as this is more "Rack the server implementations". rack/rack#1928

The simplest solution is for Falcon just to support the defacto "#stop" method and we can provide a wrapper from Rack::Handler::Falcon.run which supports this interface in the Falcon gem - I'll work on that today, and it won't impact the 3.0 release of Sinatra - you can merge the PR and I'll fix it on my end. There isn't any extra work that needs to be done in sinatra right now IMHO.

Going forward, you might like to evaluate HOW sinatra start servers. The Rack::Handler infrastructure isn't well defined but I think we should improve it. Looking to sinatra, I see two parts: starting the server, and handling interrupts to stop it. But this makes a number of assumptions about when it's safe to call #stop. Calling #stop from signal handlers might not be safe - I'll make sure Falcon supports that, but I'm not sure about other servers. Calling webrick #stop from a signal handler probably isn't safe - it might be, but I wouldn't bet on it!

Falcon v0.40.1 is released and should work well with Sinatra.

Wow thank you @ioquatix!!

It's a shame SASS had to go. We use SASS, Coffeescript and Slim in our apps. But fortunately the first 2 are used only for convenience for the on-the-fly compilation during development, for deployment we use precompiled resources anyway, so it shouldn't harm us that much.

SASS could always be added back, if someone takes responsibility for it and contributes. Are you using any of the the not so maintained gems (ruby-sass, sassc-ruby) @raxoft or something else? Just saw https://github.com/ntkme/sassc-embedded-shim-ruby + https://github.com/ntkme/sass-embedded-host-ruby (linked in sass/sassc-ruby#220)

We are using sassc-ruby ATM. But it's true that that game looks abandoned for quite some time now, so perhaps switching to something else might help. However I am leaving for two weeks vacation in couple of days, so I am afraid I can't explore those options now. But as you said, it can always be added later again. It's just that my line of thinking was that when building an app, in general you need HTML templates, CSS and JS. So it would be nice if sinatra ships with something for each of these out of the box. 🤷‍♂️

I think people are starting to question if you still need SASS, example: thoughtbot/administrate#2116 (comment)

also, sure, that would be nice but the reality is that Sinatra is barley alive as a project and few have incitement to develop and maintain it for others, for free

It's just that my line of thinking was that when building an app, in general you need HTML templates, CSS and JS. So it would be nice if sinatra ships with something for each of these out of the box

You have a point here, however I think that instead of supporting sass, coffescript, and N engines for assets a gem that is specialized in working with assets and precompiling them for production like Sinatra Asset Pipeline (note: I haven't used it) could be used instead

Rack 3 will be released soon and will change a number of things. A 3.0 release of Sinatra is great, and it will live for a long time I am sure, be aware that enough will be changing that I imagine you will want to make a Sinatra 4.0 for Rack 3+. Just a heads up and maybe worth considering for the longer term plan.

@jkowens Like how it was done for "decompile"? It can still be loaded but only thing it does is print a warning. e48eac3#diff-dbd6906666d08a2c144fe245966fdff82eff3bc9d94982b2448898b44ffe5184

If there's demand for it, it could always be extracted to a separate repo later, to make it easier for people still wanting to use it.

I did see that for decompile, but that looks more like immediate removal with a warning than deprecation 😅

We can extract deprecated extensions to their own repository now, add them as dependencies of sinatra-contrib (so everything keeps working as it is now) and show a warning when requiring them.

Then in later releases of contrib we can drop that dependency.

@jkowens True but if we're talking Sinatra 3 my thinking was we can make such breaking changes :)

Very true, I just think we should generally allow people to upgrade and still use deprecated extensions if they choose. Maybe that isn't necessary for reloader, but I think we might want to do that if any of the other extensions need to be deprecated.

I'm leaning towards updating the rdoc (and other documentation) to make it clear reloader is deprecated. Then in the v4 release just delete it 😅

Ah I found the cop that was the issue. If anyone is able to give that PR another look that would be appreciated 👍

Maybe due to https://github.com/ruby/setup-ruby/releases/tag/v1.113.0

Try running CI with latest bundler always

https://github.com/sparklemotion/nokogiri/pull/2618/files Example PR which fixed it for another project.

Nice, thanks @olleolleolle. It's weird, now it also looks like Tilt is causing test failures 😢

Those look like keyword arguments arity issues.

It was an issue with a new release of Hamlit, details in #1809

Hmm, personally, if Sinatra 3.0 brings breaking changes, I would rather prefer if it is based on Rack 3.0 already, so I can upgrade both at once. Otherwise I would be inclined to wait for 4.0 anyway so I don't have to do the work twice.

I would not prefer that, I like smaller updates, also it sounds from @jkowens it isn't even possible.

I agree with this: "I'm thinking we should release Sinatra 3 with Rack 2 support and the follow up with a Sinatra 4 release that moves to Rack 3"

I suspect upgrading to Sinatra 3 will be fairly trivial for most applications, so I'm leaning towards releasing Sinatra 3 as is unless there is a way to support both Rack 2 and 3. @ioquatix have you had a chance to investigate supporting both with rack-session?

Sinatra should probably declare it's dependency on rack >= 2 and then users should expect to add specifically what version they want in their gemfile, including a dependency on rack-session if needed.

If Sinatra has a hard dependency on rack-session, maybe you can release sinatra-session or Sinatra-rack which has one release depending on rack ~> 2.0 and another release depending on rack ~> 3.0 + rack-session. I'm not sure if this will work but it's my best idea.

Thanks @ioquatix, I appreciate the feedback. Sinatra does have a hard dependency on rack-session. I'm getting the sense that it will just be easier to release Sinatra 3 on Rack 2 and then then move forward with Sinatra 4 on Rack 3. I think I'll aim to cut a release this weekend so we can get moving on Rack 3 support.

Whatever way you choose, thanks for your hard work.

It might be nice to get some input from Bundler/RubyGems team on whether we can put version dependent dependencies. We could also have a "null" release of rack-session which is pinned to Rack 2, and then have another release with the actual code with a requirement on rack 3+. If you want to explore supporting both Rack 2 and Rack 3 in Sinatra 3, I'll be happy to help figure out the options.

Nice! I'm happy to help. There are still some open questions about the best way to handle rack-session. Maybe it's best just to move forward and don't support Rack 2. Most applications should prefer Rack 3 going forward. In a world where Rack 2 and Rack 3 exist, there is not much point to support Rack 2 for frameworks.

You could consider keeping 3.0.x as Rack 2 and maintain it (bug fixes etc), but use 3.1+ as Rack 3 + new features/development.