ETA for v4? about authorization HOT 18 CLOSED

Days or weeks: ) One-two weeks. There were many issues in this repository, which would be good to solve in v4. Otherwise, I will have to do the v5 right after the v4 release. I want to include in v4 as more pending features as I can.

from authorization.

Hey! Is there any update on when v4 will be released? :)

from authorization.

I am also eagerly awaiting this update. Can we just get this breaking change (broken by GraphQL V4 update) fix out as soon as possible? Personally, I really don't mind if V5 comes quickly after, having this working is far more important to me.

from authorization.

https://github.com/graphql-dotnet/authorization/releases/tag/4.0.0

from authorization.

I'm sorry for the delay. I give an OSS almost all free time, which I have not so much lately. To think about and make all changes, check them and test takes a lot of time. We have several projects on support. It's impossible to manage everything In a limited time. Will have to wait.

from authorization.

hi @sungam3r, I am also interested in V4. How can I help to start contributing to this project in general?

from authorization.

By the way you can use auth package (ASP.NET Core related things) from the server project.

from authorization.

There is no ETA yet. Too much daily work.

from authorization.

The holdup is #128 , I believe, which @sungam3r and @joemcbride were working on. I'm not sure how you or I can help @rmarteleto .

There were many issues in this repository, which would be good to solve in v4. Otherwise, I will have to do the v5 right after the v4 release. I want to include in v4 as more pending features as I can.

@sungam3r If you have set aside working on #128, and if the current version compiles and is usable, we should release it, and release v5 if and when #128 is complete. It is irresponsible of us as maintainers of an OSS project to have projects remain in 'limbo' for an extended time when a version could be released that would work for users. Please let me know @sungam3r and @joemcbride if you have differing thoughts on this.

Same is also true of the relay project. If we are not going to work on it, we should release whatever code is there now, considering it has already been updated to the latest version of GraphQL. (We should review graphql-dotnet/relay#88 first and update the workflow scripts.) Or mark the entire project as deprecated, if that is the case. Ref: graphql-dotnet/relay#27

from authorization.

Hi all

I was having the same issue than @julienFlexsoft.

Let me know if I can help in something related to this release.

from authorization.

@Shane32 My major concern is that the current refactor removes functionality that users of the framework may depend on, as well as makes it more complicated to use. You could previously fully evaluate policies outside the context of the GraphQL Rule. With the refactor that is no longer the case. So if anyone was relying upon that behavior they would now have to write code that the framework should handle. There are also a bunch of classes added that make it more complicated to use and seem entirely unnecessary to support V4. It seems like @sungam3r wants to add a bunch of new features in addition to upgrading to V4. I think those should be done separately so they can be evaluated separately. I don't think what is currently there should be shipped.

from authorization.

I understand. But can we ship it without #128 ? Or does it need work (one way or another) before another version can be released? I've not been really following this repo and, not having used this project, have no opinion on its design. I just think if it's not going to be worked on, it should be released without #128 -- or no?

from authorization.

@Shane32 It looks like there is another commit on the main branch which has upgrades for V4 that looks like it could go out. The main CI is breaking on upgrading to v4.2.0, not sure why (looks like a github actions issue vs. a failing test issue).

from authorization.

@Shane32 Looks like there are a few other changes required, due to having some classes from this library moved to the core library. Looking at that.

from authorization.

#148 fixes those issues and should be able to be shipped. I think we'll just need to remove the -preview from the .csproj to create an official release.

from authorization.

All releases are published via publish workflow, no need to remove -preview. I will return to work on #128 today. In fact, there are not so many corrections for comments. We will be able to discuss the corrected version and release v4 with or without #128.

from authorization.

I will return to work on #128 today

Ok then we will hold off on another release for the moment.

from authorization.

I thought again and let's publish as it is. It is not known how much it still will be delayed.

from authorization.