Noticed, but didn't really read through until now and I optimistically thought it was more esoteric than it seems it is. Undoubtedly it's an issue with native sessions only but that's one of the strong points for Shiro. I assume you are already looking into it? Should be easy to create a test case for it. It's a simple matter to rollback the release now that we've tested the process works.
Kalle On Thu, May 20, 2010 at 11:36 AM, Les Hazlewood <[email protected]> wrote: > Sure, I'd love to! But did you see this? > > https://issues.apache.org/jira/browse/SHIRO-167 > > httpServletRequest.getSession().getServletContext() always returning > null doesn't sound great. Shouldn't we fix it quickly and re-try? > > On Thu, May 20, 2010 at 10:53 AM, Kalle Korhonen > <[email protected]> wrote: >> How about that, the release worked on the first try. Guess I've >> learned a thing or two about releasing with Maven along the way. Props >> to Maven folks for super clear yet concise instructions. >> >> The staging repository is at >> https://repository.apache.org/content/repositories/orgapacheshiro-002/ >> The Maven site/documentation is at >> http://incubator.apache.org/shiro/static/1.0.0-incubating. This is the >> final location for the site. >> >> Les, would you like to do the honors and send the official vote email >> out? There's a sample template at >> http://maven.apache.org/developers/release/apache-release.html. Since >> it's our first release though maybe you want to add a bit more >> description and maybe mention that since there were some last minute >> package changes people should actually test the binaries before >> voting, perhaps extend the voting time from minimum 72 hours. >> >> Kalle >> >> >> On Mon, Dec 7, 2009 at 10:46 AM, Kalle Korhonen >> <[email protected]> wrote: >>> On that note, I think we should release 1.0.0. Current Maven >>> versioning scheme works "best" with x.x.x numbering (see >>> http://mojo.codehaus.org/versions-maven-plugin/version-rules.html). >>> It'd also would make sensible to then reserve the incremental version >>> (the last component) for bug fixes and allow using minor versions for >>> new (compatible) feature releases. In essence, after releasing 1.0.0, >>> we'd prepare the trunk for development of 1.1.0 and create 1.0.x >>> branch for bug fixes and continue feature development, bug fixes etc. >>> in the trunk until we identify a feature set we don't want to or won't >>> make it to the next release, at which time we'd pull a 1.1x branch and >>> update the trunk for development of 1.2.x (or even 2.0.x). >>> >>> Kalle >>> >>> >>> On Mon, Dec 7, 2009 at 7:44 AM, Les Hazlewood <[email protected]> wrote: >>>> I think most people in the Shiro community would agree that we're long >>>> overdue for our first release ;) >>>> >>>> So, to that end, and unless anyone objects, I'm going to take a crack >>>> at tagging only what I feel are the most important issues that >>>> absolutely must be in to 1.0. When I'm done with that, I'd like to >>>> post to this list again to allow people the opportunity to speak-up if >>>> they see something that they think should be included but I missed. >>>> >>>> I'm doing this to help us get a little focus on what should concretely >>>> define our first release, and to get it out as soon as possible from >>>> now. Just my opinion, but I think it'd be great if we can finish all >>>> the 1.0 issues (if not actually release) by 1 January. >>>> >>>> Please let me know if anyone does not agree with this, otherwise, I'll >>>> get started as soon as possible organizing the existing issues. >>>> >>>> Thanks, >>>> >>>> Les >>>> >>> >> >
