For future googlers the ExceptionCatchingModularRealmAuthorizer bits are tracked by: https://issues.apache.org/jira/browse/SHIRO-348
On Fri, Apr 15, 2011 at 1:55 PM, Les Hazlewood <[email protected]>wrote: > Yeah, I personally would feel a lot more comfortable with this. I > think the best way to go about doing this is deprecate them as you > said and then also create a Jira issue to ensure that it is visible > when we release 2.0. From the Jira issues, we can create a 'what's > changed in 2.0' documentation page that will make these things very > clear. > > Les > > On Fri, Apr 15, 2011 at 7:30 AM, Brian Demers <[email protected]> > wrote: > > Agreed. > > > > Maybe we should revert the changes, then deprecate the methods in the > > Realm interface. That _may_ give people a heads up. and in the 2.0 we > > pull them out. I not 100% sure that would have the desired effect > > without seeing how the deprecation errors would propagate across the > > source. > > > > > > > > > > On Thu, Apr 14, 2011 at 2:22 PM, Les Hazlewood <[email protected]> > wrote: > >> On Thu, Apr 14, 2011 at 8:45 AM, Brian Demers <[email protected]> > wrote: > >>> Yeah, changing the Realm interface defiantly violates the versioning > >>> guidelines. Is there anything saying the next release cannot be 2.0 > >>> (granted that doesn't change the problem here) > >> > >> Nope, nothing that says that, but 2.0 is probably a large enough scope > >> that it means we won't have a release in a long time. I'd rather not > >> hold off what could be 6 to 9 months before getting our next release > >> out. IMO that's a stifling thing to do for a community that is > >> currently picking up a huge amount of steam (~ %20 traffic increase > >> compounded per month) > >> > >> Here is some of the stuff discussed for version 2: > >> > >> > https://cwiki.apache.org/confluence/display/SHIRO/Version+2+Brainstorming > >> > >> Please feel free to add your own ideas! > >> > >>> On the plus side, I think my ExceptionCatchingModularRealmAuthorizer > >>> was the only think that broke, which highlights a contribution. > >> > >> Yep, but we have no idea how many other custom Authorizer > >> implementations there are. That could leave a bad taste in the mouths > >> of those people - not something I'd like to risk. > >> > >> It is very important to me that, as a security framework, we create > >> releases with stability and consistency in mind, especially now that > >> we're past 1.0. > >> > >> My .02, > >> > >> Les >
