Actix-web: Breaking change in 1.0.2

[killercup]

https://github.com/actix/actix-web/commit/546a8a58db0e9f985310ae1ed56878a089f7ba09 introduced a breaking change: It removed support for CORS, an API that previously enabled by default. The deprecation period was also super short: From what I can tell, there were two patch releases on the same day -- one that introduced the deprecation notice and and one that removed it. From my understanding of semver patch releases should never remove APIs that were previously stable, and only major releases would remove deprecated items.

I'm writing this simple because this change just broke a cargo update on a project we use in production and a coworker asked for my help because this was very unexpected -- every other crate seemed to adhere to semver so far and all updates were seamless. I know the required change is quite small (we have already fixed it), but learning what is actually required from reading this random commit was also not the best experience. I know actix-web has been actively developed for quite a while, I have seen the maintainers continue to deliver great stuff, and you just released 1.0; so hitting an issue like this not even a month after starting to use it in a team is honestly disappointing.

I would suggest you either add a re-export of actix_cors::Cors as actix_web::middleware::cors::Cors and yank 1.0.2 and 1.0.3, thus reverting the breaking change. Or, alternatively, yank 1.0.0 which is the only non-yanked version that included it (from what I can tell). Also, we would appreciate it if the change log could have a bit more details on this. (And maybe also explain why 1.0.1 was yanked?)

[fafhrd91]

It is not possible to have circular references, which I didn’t know. So I had to yank 1.0.1 and release 1.0.2 without cors.

[killercup]

Okay. This is still a breaking change when updating from 1.0.0. Can you yank that version, too, and add some information on this issue to the change log? So other people running into this know what to do?

[fafhrd91]

i dont see reason

[killercup]

Lol, the reason is that it's super surprising that updating from 1.0.0 breaks the project.

[ghost]

@killercup

I can show you some points:

• I think this project is not well designed. Its core performance is based on mio crate as root. Nothing new is introduced here.
• Maintainers _clearly_ don't follow semver -- which is totally fine -- it's their project. I also think maintainers _clearly_ don't try to understand semver (which I think they don't understand semver right now).

In my own opinion, currently you should make something on top of hyper crate.

In my own experiences. If you care enough to file this issue, you can make your own framework quiet easily. For years of my software life, I think the best way is to do things from scratch.

I don't mean to say bad words about maintainers here. I'm just saying their goals don't meet mine. And from my view, their goals don't meet yours either.

It's better to depart.

[neoeinstein]

While this break was unexpected, the fix (at least for my projects) was quick and easy (add a reference and use actix-cors) . I would consider it a hiccup in commencing with semver more than a "_clearly_" won't follow it. We as maintainers can take it as feedback for future releases. Damage done is damage done.

@K7JsV6t6w it's fine if you don't want to use actix, but not all that helpful to leave a hollow negative comment on an old issue saying "don't use this crate" and "this project is not well-designed". I would be happy to read a blog post or article where you critique the things you might do differently in our framework. Despite that, I don't think this thread is the appropriate space to air this grievance.