You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@shiro.apache.org by Les Hazlewood <lh...@apache.org> on 2009/12/07 16:44:01 UTC

Preparing for our first release

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

Re: Preparing for our first release

Posted by Brian Demers <br...@gmail.com>.

I know I am a bit partial, but I would like to see SHIRO-59 (patch attached)
get in.
-Brian

On Mon, Feb 1, 2010 at 10:54 PM, Kalle Korhonen
<ka...@gmail.com>wrote:

> I think it's a high time to do our first release. There's quite a few
> smallish organizational and/or configuration items we need to do
> before a release, most of them nicely tracked at
> http://incubator.apache.org/clutch.html. Color-wise, we are not doing
> that bad but we could do better. Don't care about the all green much
> but the page is tracking the right items, so I just picked up the
> hammer and I'll start swinging. I'll be updating the progress here and
> in case I run into issues. I'll first create the distribution area and
> publish our site docs there. If there are any open issues any of you
> would like to get closed before 1.0.0 better start working on them
> now.. I don't think we are going to wait for all of the issues
> currently scheduled for 1.0
> (
> https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=12310950&fixfor=12314078
> )
> to be completed unless they are critical/blocker. We'll just schedule
> them for a later point release if not done until we are otherwise
> ready for 1.0.0. Agree?
>
> Kalle
>
>
> On Fri, Dec 18, 2009 at 1:19 PM, Les Hazlewood <lh...@apache.org>
> wrote:
> > Thanks!
> >
> > On Fri, Dec 18, 2009 at 4:17 PM, Alan D. Cabrera <li...@toolazydogs.com>
> wrote:
> >> Done.
> >>
> >>
> >> Regards,
> >> Alan
> >>
> >> On Dec 18, 2009, at 1:06 PM, Les Hazlewood wrote:
> >>
> >>> In light of this, could you please resolve the following issue?
> >>>
> >>> https://issues.apache.org/jira/browse/SHIRO-41
> >>>
> >>> Thanks,
> >>>
> >>> Les
> >>>
> >>> On Wed, Dec 16, 2009 at 11:16 AM, Alan D. Cabrera <
> list@toolazydogs.com>
> >>> wrote:
> >>>>
> >>>> For artwork it can get complicated but only if you received
> stipulations
> >>>> on
> >>>> its usage; it doesn't seem that there is any.  I think we're good
> here.
> >>>>
> >>>>
> >>>> Regards,
> >>>> Alan
> >>>>
> >>>> On Dec 16, 2009, at 7:33 AM, Les Hazlewood wrote:
> >>>>
> >>>>> There is one minor thing I forgot to mention:  Jeremy's friend
> created
> >>>>> the old JSecurity shield/lock logo for us.  He did the logo for us in
> >>>>> return for free website hosting on one of our servers.  This is
> >>>>> payment for services rendered (he payed us by doing the logo work,
> the
> >>>>> services rendered were the website hosting), so I don't think that we
> >>>>> need a CLA/sign-off from him.
> >>>>>
> >>>>> As I understand it, the shield/lock logo is our intellectual property
> >>>>> due to this agreement and we don't need to involve him.  IANAL, but I
> >>>>> think we're ok.
> >>>>>
> >>>>> - Les
> >>>>>
> >>>>> On Wed, Dec 16, 2009 at 10:26 AM, Les Hazlewood <
> lhazlewood@apache.org>
> >>>>> wrote:
> >>>>>>
> >>>>>> Yep, it did.  Just for clarity's sake: every contributor on the old
> >>>>>> JSecurity project came over as a committer to Apache and each also
> >>>>>> sent the re-licensing agreement/affirmation at that time.
> >>>>>>
> >>>>>> Cheers,
> >>>>>>
> >>>>>> Les
> >>>>>>
> >>>>>> On Wed, Dec 16, 2009 at 10:22 AM, Alan D. Cabrera
> >>>>>> <li...@toolazydogs.com>
> >>>>>> wrote:
> >>>>>>>
> >>>>>>> So, back in July Craig sent out a set of emails from committers in
> the
> >>>>>>> project stating that re-licensing for ASF.  What I am not sure of
> is
> >>>>>>> that
> >>>>>>> this covers *all* the original authors from the JSecurity project
> >>>>>>> before
> >>>>>>> it
> >>>>>>> arrived at the Incubator.
> >>>>>>>
> >>>>>>>
> >>>>>>> Regards,
> >>>>>>> Alan
> >>>>>>>
> >>>>>>> On Dec 8, 2009, at 6:42 AM, Les Hazlewood wrote:
> >>>>>>>
> >>>>>>>> Craig, can you please just confirm this so we have a clear record
> of
> >>>>>>>> it?
> >>>>>>>>
> >>>>>>>> Thanks,
> >>>>>>>>
> >>>>>>>> Les
> >>>>>>>>
> >>>>>>>> On Tue, Dec 8, 2009 at 9:26 AM, Alan D. Cabrera
> >>>>>>>> <li...@toolazydogs.com>
> >>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>> If Craig has confirmed that all the original authors from
> JSecurity
> >>>>>>>>> have
> >>>>>>>>> filed a license agreement then I think we're good.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Regards,
> >>>>>>>>> Alan
> >>>>>>>>>
> >>>>>>>>> On Dec 7, 2009, at 4:58 PM, Les Hazlewood wrote:
> >>>>>>>>>
> >>>>>>>>>> Yep, we're covered.  All people who contributed previously to
> >>>>>>>>>> JSecurity became committers to Shiro.  Before joining the
> >>>>>>>>>> incubator,
> >>>>>>>>>> we all formally (each) agreed to the transfer.
> >>>>>>>>>>
> >>>>>>>>>> HTH,
> >>>>>>>>>>
> >>>>>>>>>> Les
> >>>>>>>>>>
> >>>>>>>>>> On Mon, Dec 7, 2009 at 5:27 PM, Alan D. Cabrera
> >>>>>>>>>> <li...@toolazydogs.com>
> >>>>>>>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>> I recall that agreements were forwarded by current project
> >>>>>>>>>>> members.
> >>>>>>>>>>>  I'm
> >>>>>>>>>>> not
> >>>>>>>>>>> certain that we covered all the people who contributed to the
> >>>>>>>>>>> original
> >>>>>>>>>>> project.
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> Regards,
> >>>>>>>>>>> Alan
> >>>>>>>>>>>
> >>>>>>>>>>> On Dec 7, 2009, at 11:40 AM, Les Hazlewood wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> To the best of my knowledge this is all finished - Craig
> helped
> >>>>>>>>>>>> out
> >>>>>>>>>>>> with it.  I forwarded all the formal statements from all
> previous
> >>>>>>>>>>>> committers that they fully agree and support of transferring
> all
> >>>>>>>>>>>> of
> >>>>>>>>>>>> their work to the ASF 2.0 license.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Craig, could you please clarify if there's anything else that
> >>>>>>>>>>>> needs
> >>>>>>>>>>>> to
> >>>>>>>>>>>> be
> >>>>>>>>>>>> done?
> >>>>>>>>>>>>
> >>>>>>>>>>>> Thanks!
> >>>>>>>>>>>>
> >>>>>>>>>>>> Les
> >>>>>>>>>>>>
> >>>>>>>>>>>> On Mon, Dec 7, 2009 at 1:31 PM, Alan D. Cabrera
> >>>>>>>>>>>> <li...@toolazydogs.com>
> >>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> On Dec 7, 2009, at 7:44 AM, Les Hazlewood 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.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Sounds great!
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> The only thing that's hazy in my mind is the LGPL vetting.  I
> >>>>>>>>>>>>> recall
> >>>>>>>>>>>>> an
> >>>>>>>>>>>>> effort to obtain permission to relicense the code from the
> >>>>>>>>>>>>> original
> >>>>>>>>>>>>> authors
> >>>>>>>>>>>>> but am not sure if it was completed and all the requisite
> >>>>>>>>>>>>> permissions
> >>>>>>>>>>>>> were
> >>>>>>>>>>>>> properly filed.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Regards,
> >>>>>>>>>>>>> Alan
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>>>
> >>
> >>
> >
>

Re: Preparing for our first release

Posted by Les Hazlewood <lh...@apache.org>.

It is unlikely this will make it in to 1.0 unless someone contributed
the code for it - we've been too busy finalizing core APIs for the 1.0
release.

At the moment that issue is a placeholder until someone can dedicate
some time to it.  The sooner anyone (not just the dev team) can
contribute something, the sooner it will make it in.  Hopefully
someone in the community can find some time for it!

Cheers,

Les

On Fri, Feb 5, 2010 at 9:13 AM, Tauren Mills <yo...@gmail.com> wrote:
> What kind of priority does OAuth support have? I see there is an issue for
> it: https://issues.apache.org/jira/browse/SHIRO-119.  I'd like to see Shiro
> support it sooner than later, but then again, I wouldn't want to hold up the
> release for it.  Is it just a wish for someday, or is it actually a planned
> feature?
>
> Tauren
>
>
> On Mon, Feb 1, 2010 at 9:41 PM, Kalle Korhonen
> <ka...@gmail.com>wrote:
>
>> Ha! I knew that would get the ball rolling :) I'll take care of
>> SHIRO-59. Agree with everything Les said - API changes would be
>> important to get in at this stage. I expect working through the
>> release preparation will still take a couple of weeks and we probably
>> have a good chance of closing out all of the remaining ones currently
>> scheduled in that timeframe - but there's no point holding up the
>> release if not.
>>
>> Kalle
>>
>>
>> On Mon, Feb 1, 2010 at 8:39 PM, Les Hazlewood <lh...@apache.org>
>> wrote:
>> > I definitely agree - there are a few critical issues that I'd like to
>> > see if we can resolve:
>> >
>> > -  The RememberMeManager acquires the HttpServletRequest/Response pair
>> > from the ThreadLocal - I was thinking that might require an API change
>> > to the RememberMeManager to accept it as a method argument or in the
>> > Subject context map.
>> > - 'Run As' is about 50% done.  It shouldn't take much longer to finish
>> > - As Brian suggested, his patches would be a nice edition for the 1.0
>> release.
>> >
>> > I agree that most of the other issues won't be done for the 1.0
>> > release, but that's ok - that's what 1.1 will be for or 1.2 or
>> > whatever.  It's definitely a good idea to get 1.0 out now to service
>> > the community's needs.
>> >
>> > We're definitely close!
>> >
>> > Cheers,
>> >
>> > Les
>> >
>> > On Mon, Feb 1, 2010 at 10:54 PM, Kalle Korhonen
>> > <ka...@gmail.com> wrote:
>> >> I think it's a high time to do our first release. There's quite a few
>> >> smallish organizational and/or configuration items we need to do
>> >> before a release, most of them nicely tracked at
>> >> http://incubator.apache.org/clutch.html. Color-wise, we are not doing
>> >> that bad but we could do better. Don't care about the all green much
>> >> but the page is tracking the right items, so I just picked up the
>> >> hammer and I'll start swinging. I'll be updating the progress here and
>> >> in case I run into issues. I'll first create the distribution area and
>> >> publish our site docs there. If there are any open issues any of you
>> >> would like to get closed before 1.0.0 better start working on them
>> >> now.. I don't think we are going to wait for all of the issues
>> >> currently scheduled for 1.0
>> >> (
>> https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=12310950&fixfor=12314078
>> )
>> >> to be completed unless they are critical/blocker. We'll just schedule
>> >> them for a later point release if not done until we are otherwise
>> >> ready for 1.0.0. Agree?
>> >>
>> >> Kalle
>> >>
>> >>
>> >> On Fri, Dec 18, 2009 at 1:19 PM, Les Hazlewood <lh...@apache.org>
>> wrote:
>> >>> Thanks!
>> >>>
>> >>> On Fri, Dec 18, 2009 at 4:17 PM, Alan D. Cabrera <li...@toolazydogs.com>
>> wrote:
>> >>>> Done.
>> >>>>
>> >>>>
>> >>>> Regards,
>> >>>> Alan
>> >>>>
>> >>>> On Dec 18, 2009, at 1:06 PM, Les Hazlewood wrote:
>> >>>>
>> >>>>> In light of this, could you please resolve the following issue?
>> >>>>>
>> >>>>> https://issues.apache.org/jira/browse/SHIRO-41
>> >>>>>
>> >>>>> Thanks,
>> >>>>>
>> >>>>> Les
>> >>>>>
>> >>>>> On Wed, Dec 16, 2009 at 11:16 AM, Alan D. Cabrera <
>> list@toolazydogs.com>
>> >>>>> wrote:
>> >>>>>>
>> >>>>>> For artwork it can get complicated but only if you received
>> stipulations
>> >>>>>> on
>> >>>>>> its usage; it doesn't seem that there is any.  I think we're good
>> here.
>> >>>>>>
>> >>>>>>
>> >>>>>> Regards,
>> >>>>>> Alan
>> >>>>>>
>> >>>>>> On Dec 16, 2009, at 7:33 AM, Les Hazlewood wrote:
>> >>>>>>
>> >>>>>>> There is one minor thing I forgot to mention:  Jeremy's friend
>> created
>> >>>>>>> the old JSecurity shield/lock logo for us.  He did the logo for us
>> in
>> >>>>>>> return for free website hosting on one of our servers.  This is
>> >>>>>>> payment for services rendered (he payed us by doing the logo work,
>> the
>> >>>>>>> services rendered were the website hosting), so I don't think that
>> we
>> >>>>>>> need a CLA/sign-off from him.
>> >>>>>>>
>> >>>>>>> As I understand it, the shield/lock logo is our intellectual
>> property
>> >>>>>>> due to this agreement and we don't need to involve him.  IANAL, but
>> I
>> >>>>>>> think we're ok.
>> >>>>>>>
>> >>>>>>> - Les
>> >>>>>>>
>> >>>>>>> On Wed, Dec 16, 2009 at 10:26 AM, Les Hazlewood <
>> lhazlewood@apache.org>
>> >>>>>>> wrote:
>> >>>>>>>>
>> >>>>>>>> Yep, it did.  Just for clarity's sake: every contributor on the
>> old
>> >>>>>>>> JSecurity project came over as a committer to Apache and each also
>> >>>>>>>> sent the re-licensing agreement/affirmation at that time.
>> >>>>>>>>
>> >>>>>>>> Cheers,
>> >>>>>>>>
>> >>>>>>>> Les
>> >>>>>>>>
>> >>>>>>>> On Wed, Dec 16, 2009 at 10:22 AM, Alan D. Cabrera
>> >>>>>>>> <li...@toolazydogs.com>
>> >>>>>>>> wrote:
>> >>>>>>>>>
>> >>>>>>>>> So, back in July Craig sent out a set of emails from committers
>> in the
>> >>>>>>>>> project stating that re-licensing for ASF.  What I am not sure of
>> is
>> >>>>>>>>> that
>> >>>>>>>>> this covers *all* the original authors from the JSecurity project
>> >>>>>>>>> before
>> >>>>>>>>> it
>> >>>>>>>>> arrived at the Incubator.
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>> Regards,
>> >>>>>>>>> Alan
>> >>>>>>>>>
>> >>>>>>>>> On Dec 8, 2009, at 6:42 AM, Les Hazlewood wrote:
>> >>>>>>>>>
>> >>>>>>>>>> Craig, can you please just confirm this so we have a clear
>> record of
>> >>>>>>>>>> it?
>> >>>>>>>>>>
>> >>>>>>>>>> Thanks,
>> >>>>>>>>>>
>> >>>>>>>>>> Les
>> >>>>>>>>>>
>> >>>>>>>>>> On Tue, Dec 8, 2009 at 9:26 AM, Alan D. Cabrera
>> >>>>>>>>>> <li...@toolazydogs.com>
>> >>>>>>>>>> wrote:
>> >>>>>>>>>>>
>> >>>>>>>>>>> If Craig has confirmed that all the original authors from
>> JSecurity
>> >>>>>>>>>>> have
>> >>>>>>>>>>> filed a license agreement then I think we're good.
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>> Regards,
>> >>>>>>>>>>> Alan
>> >>>>>>>>>>>
>> >>>>>>>>>>> On Dec 7, 2009, at 4:58 PM, Les Hazlewood wrote:
>> >>>>>>>>>>>
>> >>>>>>>>>>>> Yep, we're covered.  All people who contributed previously to
>> >>>>>>>>>>>> JSecurity became committers to Shiro.  Before joining the
>> >>>>>>>>>>>> incubator,
>> >>>>>>>>>>>> we all formally (each) agreed to the transfer.
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> HTH,
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> Les
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> On Mon, Dec 7, 2009 at 5:27 PM, Alan D. Cabrera
>> >>>>>>>>>>>> <li...@toolazydogs.com>
>> >>>>>>>>>>>> wrote:
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> I recall that agreements were forwarded by current project
>> >>>>>>>>>>>>> members.
>> >>>>>>>>>>>>>  I'm
>> >>>>>>>>>>>>> not
>> >>>>>>>>>>>>> certain that we covered all the people who contributed to the
>> >>>>>>>>>>>>> original
>> >>>>>>>>>>>>> project.
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> Regards,
>> >>>>>>>>>>>>> Alan
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> On Dec 7, 2009, at 11:40 AM, Les Hazlewood wrote:
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>> To the best of my knowledge this is all finished - Craig
>> helped
>> >>>>>>>>>>>>>> out
>> >>>>>>>>>>>>>> with it.  I forwarded all the formal statements from all
>> previous
>> >>>>>>>>>>>>>> committers that they fully agree and support of transferring
>> all
>> >>>>>>>>>>>>>> of
>> >>>>>>>>>>>>>> their work to the ASF 2.0 license.
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>> Craig, could you please clarify if there's anything else
>> that
>> >>>>>>>>>>>>>> needs
>> >>>>>>>>>>>>>> to
>> >>>>>>>>>>>>>> be
>> >>>>>>>>>>>>>> done?
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>> Thanks!
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>> Les
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>> On Mon, Dec 7, 2009 at 1:31 PM, Alan D. Cabrera
>> >>>>>>>>>>>>>> <li...@toolazydogs.com>
>> >>>>>>>>>>>>>> wrote:
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> On Dec 7, 2009, at 7:44 AM, Les Hazlewood 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.
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> Sounds great!
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> The only thing that's hazy in my mind is the LGPL vetting.
>>  I
>> >>>>>>>>>>>>>>> recall
>> >>>>>>>>>>>>>>> an
>> >>>>>>>>>>>>>>> effort to obtain permission to relicense the code from the
>> >>>>>>>>>>>>>>> original
>> >>>>>>>>>>>>>>> authors
>> >>>>>>>>>>>>>>> but am not sure if it was completed and all the requisite
>> >>>>>>>>>>>>>>> permissions
>> >>>>>>>>>>>>>>> were
>> >>>>>>>>>>>>>>> properly filed.
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> Regards,
>> >>>>>>>>>>>>>>> Alan
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>
>> >>>>
>> >>>
>> >>
>> >
>>
>

Re: Preparing for our first release

Posted by Tauren Mills <yo...@gmail.com>.

What kind of priority does OAuth support have? I see there is an issue for
it: https://issues.apache.org/jira/browse/SHIRO-119.  I'd like to see Shiro
support it sooner than later, but then again, I wouldn't want to hold up the
release for it.  Is it just a wish for someday, or is it actually a planned
feature?

Tauren


On Mon, Feb 1, 2010 at 9:41 PM, Kalle Korhonen
<ka...@gmail.com>wrote:

> Ha! I knew that would get the ball rolling :) I'll take care of
> SHIRO-59. Agree with everything Les said - API changes would be
> important to get in at this stage. I expect working through the
> release preparation will still take a couple of weeks and we probably
> have a good chance of closing out all of the remaining ones currently
> scheduled in that timeframe - but there's no point holding up the
> release if not.
>
> Kalle
>
>
> On Mon, Feb 1, 2010 at 8:39 PM, Les Hazlewood <lh...@apache.org>
> wrote:
> > I definitely agree - there are a few critical issues that I'd like to
> > see if we can resolve:
> >
> > -  The RememberMeManager acquires the HttpServletRequest/Response pair
> > from the ThreadLocal - I was thinking that might require an API change
> > to the RememberMeManager to accept it as a method argument or in the
> > Subject context map.
> > - 'Run As' is about 50% done.  It shouldn't take much longer to finish
> > - As Brian suggested, his patches would be a nice edition for the 1.0
> release.
> >
> > I agree that most of the other issues won't be done for the 1.0
> > release, but that's ok - that's what 1.1 will be for or 1.2 or
> > whatever.  It's definitely a good idea to get 1.0 out now to service
> > the community's needs.
> >
> > We're definitely close!
> >
> > Cheers,
> >
> > Les
> >
> > On Mon, Feb 1, 2010 at 10:54 PM, Kalle Korhonen
> > <ka...@gmail.com> wrote:
> >> I think it's a high time to do our first release. There's quite a few
> >> smallish organizational and/or configuration items we need to do
> >> before a release, most of them nicely tracked at
> >> http://incubator.apache.org/clutch.html. Color-wise, we are not doing
> >> that bad but we could do better. Don't care about the all green much
> >> but the page is tracking the right items, so I just picked up the
> >> hammer and I'll start swinging. I'll be updating the progress here and
> >> in case I run into issues. I'll first create the distribution area and
> >> publish our site docs there. If there are any open issues any of you
> >> would like to get closed before 1.0.0 better start working on them
> >> now.. I don't think we are going to wait for all of the issues
> >> currently scheduled for 1.0
> >> (
> https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=12310950&fixfor=12314078
> )
> >> to be completed unless they are critical/blocker. We'll just schedule
> >> them for a later point release if not done until we are otherwise
> >> ready for 1.0.0. Agree?
> >>
> >> Kalle
> >>
> >>
> >> On Fri, Dec 18, 2009 at 1:19 PM, Les Hazlewood <lh...@apache.org>
> wrote:
> >>> Thanks!
> >>>
> >>> On Fri, Dec 18, 2009 at 4:17 PM, Alan D. Cabrera <li...@toolazydogs.com>
> wrote:
> >>>> Done.
> >>>>
> >>>>
> >>>> Regards,
> >>>> Alan
> >>>>
> >>>> On Dec 18, 2009, at 1:06 PM, Les Hazlewood wrote:
> >>>>
> >>>>> In light of this, could you please resolve the following issue?
> >>>>>
> >>>>> https://issues.apache.org/jira/browse/SHIRO-41
> >>>>>
> >>>>> Thanks,
> >>>>>
> >>>>> Les
> >>>>>
> >>>>> On Wed, Dec 16, 2009 at 11:16 AM, Alan D. Cabrera <
> list@toolazydogs.com>
> >>>>> wrote:
> >>>>>>
> >>>>>> For artwork it can get complicated but only if you received
> stipulations
> >>>>>> on
> >>>>>> its usage; it doesn't seem that there is any.  I think we're good
> here.
> >>>>>>
> >>>>>>
> >>>>>> Regards,
> >>>>>> Alan
> >>>>>>
> >>>>>> On Dec 16, 2009, at 7:33 AM, Les Hazlewood wrote:
> >>>>>>
> >>>>>>> There is one minor thing I forgot to mention:  Jeremy's friend
> created
> >>>>>>> the old JSecurity shield/lock logo for us.  He did the logo for us
> in
> >>>>>>> return for free website hosting on one of our servers.  This is
> >>>>>>> payment for services rendered (he payed us by doing the logo work,
> the
> >>>>>>> services rendered were the website hosting), so I don't think that
> we
> >>>>>>> need a CLA/sign-off from him.
> >>>>>>>
> >>>>>>> As I understand it, the shield/lock logo is our intellectual
> property
> >>>>>>> due to this agreement and we don't need to involve him.  IANAL, but
> I
> >>>>>>> think we're ok.
> >>>>>>>
> >>>>>>> - Les
> >>>>>>>
> >>>>>>> On Wed, Dec 16, 2009 at 10:26 AM, Les Hazlewood <
> lhazlewood@apache.org>
> >>>>>>> wrote:
> >>>>>>>>
> >>>>>>>> Yep, it did.  Just for clarity's sake: every contributor on the
> old
> >>>>>>>> JSecurity project came over as a committer to Apache and each also
> >>>>>>>> sent the re-licensing agreement/affirmation at that time.
> >>>>>>>>
> >>>>>>>> Cheers,
> >>>>>>>>
> >>>>>>>> Les
> >>>>>>>>
> >>>>>>>> On Wed, Dec 16, 2009 at 10:22 AM, Alan D. Cabrera
> >>>>>>>> <li...@toolazydogs.com>
> >>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>> So, back in July Craig sent out a set of emails from committers
> in the
> >>>>>>>>> project stating that re-licensing for ASF.  What I am not sure of
> is
> >>>>>>>>> that
> >>>>>>>>> this covers *all* the original authors from the JSecurity project
> >>>>>>>>> before
> >>>>>>>>> it
> >>>>>>>>> arrived at the Incubator.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Regards,
> >>>>>>>>> Alan
> >>>>>>>>>
> >>>>>>>>> On Dec 8, 2009, at 6:42 AM, Les Hazlewood wrote:
> >>>>>>>>>
> >>>>>>>>>> Craig, can you please just confirm this so we have a clear
> record of
> >>>>>>>>>> it?
> >>>>>>>>>>
> >>>>>>>>>> Thanks,
> >>>>>>>>>>
> >>>>>>>>>> Les
> >>>>>>>>>>
> >>>>>>>>>> On Tue, Dec 8, 2009 at 9:26 AM, Alan D. Cabrera
> >>>>>>>>>> <li...@toolazydogs.com>
> >>>>>>>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>> If Craig has confirmed that all the original authors from
> JSecurity
> >>>>>>>>>>> have
> >>>>>>>>>>> filed a license agreement then I think we're good.
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> Regards,
> >>>>>>>>>>> Alan
> >>>>>>>>>>>
> >>>>>>>>>>> On Dec 7, 2009, at 4:58 PM, Les Hazlewood wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> Yep, we're covered.  All people who contributed previously to
> >>>>>>>>>>>> JSecurity became committers to Shiro.  Before joining the
> >>>>>>>>>>>> incubator,
> >>>>>>>>>>>> we all formally (each) agreed to the transfer.
> >>>>>>>>>>>>
> >>>>>>>>>>>> HTH,
> >>>>>>>>>>>>
> >>>>>>>>>>>> Les
> >>>>>>>>>>>>
> >>>>>>>>>>>> On Mon, Dec 7, 2009 at 5:27 PM, Alan D. Cabrera
> >>>>>>>>>>>> <li...@toolazydogs.com>
> >>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> I recall that agreements were forwarded by current project
> >>>>>>>>>>>>> members.
> >>>>>>>>>>>>>  I'm
> >>>>>>>>>>>>> not
> >>>>>>>>>>>>> certain that we covered all the people who contributed to the
> >>>>>>>>>>>>> original
> >>>>>>>>>>>>> project.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Regards,
> >>>>>>>>>>>>> Alan
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> On Dec 7, 2009, at 11:40 AM, Les Hazlewood wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> To the best of my knowledge this is all finished - Craig
> helped
> >>>>>>>>>>>>>> out
> >>>>>>>>>>>>>> with it.  I forwarded all the formal statements from all
> previous
> >>>>>>>>>>>>>> committers that they fully agree and support of transferring
> all
> >>>>>>>>>>>>>> of
> >>>>>>>>>>>>>> their work to the ASF 2.0 license.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Craig, could you please clarify if there's anything else
> that
> >>>>>>>>>>>>>> needs
> >>>>>>>>>>>>>> to
> >>>>>>>>>>>>>> be
> >>>>>>>>>>>>>> done?
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Thanks!
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Les
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> On Mon, Dec 7, 2009 at 1:31 PM, Alan D. Cabrera
> >>>>>>>>>>>>>> <li...@toolazydogs.com>
> >>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> On Dec 7, 2009, at 7:44 AM, Les Hazlewood 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.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Sounds great!
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> The only thing that's hazy in my mind is the LGPL vetting.
>  I
> >>>>>>>>>>>>>>> recall
> >>>>>>>>>>>>>>> an
> >>>>>>>>>>>>>>> effort to obtain permission to relicense the code from the
> >>>>>>>>>>>>>>> original
> >>>>>>>>>>>>>>> authors
> >>>>>>>>>>>>>>> but am not sure if it was completed and all the requisite
> >>>>>>>>>>>>>>> permissions
> >>>>>>>>>>>>>>> were
> >>>>>>>>>>>>>>> properly filed.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Regards,
> >>>>>>>>>>>>>>> Alan
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>>>
> >>>>
> >>>>
> >>>
> >>
> >
>

Re: Preparing for our first release

Posted by Les Hazlewood <lh...@apache.org>.

Thanks!

On Tue, Feb 9, 2010 at 11:19 AM, Brian Demers <br...@gmail.com> wrote:
> I should have put the book link in the last email:
> http://www.sonatype.com/books/nexus-book/reference/staging.html
>
>
> On Tue, Feb 9, 2010 at 11:16 AM, Les Hazlewood <lh...@apache.org>wrote:
>
>> Ah yes - I like the Nexus UI, but I haven't used these features yet.
>> I need to crack open the Nexus documentation to find out how to do
>> this.
>>
>> Thanks again,
>>
>> Les
>>
>> On Tue, Feb 9, 2010 at 10:49 AM, Brian Demers <br...@gmail.com>
>> wrote:
>> > Hey Les,
>> >
>> > On Tue, Feb 9, 2010 at 10:32 AM, Les Hazlewood <lhazlewood@apache.org
>> >wrote:
>> >
>> >> Hi Brian,
>> >>
>> >> > To get everything setup for a staging repository
>> >> > Create a sub task under:
>> >> https://issues.apache.org/jira/browse/INFRA-1896
>> >>
>> >> Done:
>> >>
>> >> https://issues.apache.org/jira/browse/INFRA-2488
>> >>
>> >> > After the deploy you need to close the staging repo, and promote it
>> >>
>> >> What do you mean by close the staging repo?  Just ensure that the team
>> >> does not deploy to staging to prevent overwrites?
>> >>
>> >
>> > A single maven deploy is a bunch of stateless deploys so there is no way
>> to
>> > know when maven is done deploying all the artifacts.  So after you do a
>> > deploy you need to tell Nexus you are finished.  This puts the repository
>> in
>> > a read-only mode
>> >
>> > You could do this all from a maven plugin (but personally I like the UI
>> for
>> > this):
>> > http://plugins.sonatype.org/nexus-maven-plugin/usage-staging.html
>> >
>> >
>> >>
>> >> Also, once the artifacts are in staging, how is promotion done in
>> >> Nexus?  I mean, let's say that the community votes to approve the
>> >> release.  How do you propagate those voted-upon artifacts from staging
>> >> to the release repo?
>> >>
>> >
>> > The actual promoting is also just a couple clicks (or the plugin listed
>> > above)
>> > Upon promotion all the artifacts are moved into the release repository.
>> (and
>> > corresponding metadata is merged i.e. maven-metadata.xml)
>> >
>> >
>> >
>> >>
>> >> Thanks for the pointers!
>> >>
>> >> - Les
>> >>
>> >
>>
>

Re: Preparing for our first release

Posted by Brian Demers <br...@gmail.com>.

I should have put the book link in the last email:
http://www.sonatype.com/books/nexus-book/reference/staging.html


On Tue, Feb 9, 2010 at 11:16 AM, Les Hazlewood <lh...@apache.org>wrote:

> Ah yes - I like the Nexus UI, but I haven't used these features yet.
> I need to crack open the Nexus documentation to find out how to do
> this.
>
> Thanks again,
>
> Les
>
> On Tue, Feb 9, 2010 at 10:49 AM, Brian Demers <br...@gmail.com>
> wrote:
> > Hey Les,
> >
> > On Tue, Feb 9, 2010 at 10:32 AM, Les Hazlewood <lhazlewood@apache.org
> >wrote:
> >
> >> Hi Brian,
> >>
> >> > To get everything setup for a staging repository
> >> > Create a sub task under:
> >> https://issues.apache.org/jira/browse/INFRA-1896
> >>
> >> Done:
> >>
> >> https://issues.apache.org/jira/browse/INFRA-2488
> >>
> >> > After the deploy you need to close the staging repo, and promote it
> >>
> >> What do you mean by close the staging repo?  Just ensure that the team
> >> does not deploy to staging to prevent overwrites?
> >>
> >
> > A single maven deploy is a bunch of stateless deploys so there is no way
> to
> > know when maven is done deploying all the artifacts.  So after you do a
> > deploy you need to tell Nexus you are finished.  This puts the repository
> in
> > a read-only mode
> >
> > You could do this all from a maven plugin (but personally I like the UI
> for
> > this):
> > http://plugins.sonatype.org/nexus-maven-plugin/usage-staging.html
> >
> >
> >>
> >> Also, once the artifacts are in staging, how is promotion done in
> >> Nexus?  I mean, let's say that the community votes to approve the
> >> release.  How do you propagate those voted-upon artifacts from staging
> >> to the release repo?
> >>
> >
> > The actual promoting is also just a couple clicks (or the plugin listed
> > above)
> > Upon promotion all the artifacts are moved into the release repository.
> (and
> > corresponding metadata is merged i.e. maven-metadata.xml)
> >
> >
> >
> >>
> >> Thanks for the pointers!
> >>
> >> - Les
> >>
> >
>

Re: Preparing for our first release

Posted by Les Hazlewood <lh...@apache.org>.

Ah yes - I like the Nexus UI, but I haven't used these features yet.
I need to crack open the Nexus documentation to find out how to do
this.

Thanks again,

Les

On Tue, Feb 9, 2010 at 10:49 AM, Brian Demers <br...@gmail.com> wrote:
> Hey Les,
>
> On Tue, Feb 9, 2010 at 10:32 AM, Les Hazlewood <lh...@apache.org>wrote:
>
>> Hi Brian,
>>
>> > To get everything setup for a staging repository
>> > Create a sub task under:
>> https://issues.apache.org/jira/browse/INFRA-1896
>>
>> Done:
>>
>> https://issues.apache.org/jira/browse/INFRA-2488
>>
>> > After the deploy you need to close the staging repo, and promote it
>>
>> What do you mean by close the staging repo?  Just ensure that the team
>> does not deploy to staging to prevent overwrites?
>>
>
> A single maven deploy is a bunch of stateless deploys so there is no way to
> know when maven is done deploying all the artifacts.  So after you do a
> deploy you need to tell Nexus you are finished.  This puts the repository in
> a read-only mode
>
> You could do this all from a maven plugin (but personally I like the UI for
> this):
> http://plugins.sonatype.org/nexus-maven-plugin/usage-staging.html
>
>
>>
>> Also, once the artifacts are in staging, how is promotion done in
>> Nexus?  I mean, let's say that the community votes to approve the
>> release.  How do you propagate those voted-upon artifacts from staging
>> to the release repo?
>>
>
> The actual promoting is also just a couple clicks (or the plugin listed
> above)
> Upon promotion all the artifacts are moved into the release repository. (and
> corresponding metadata is merged i.e. maven-metadata.xml)
>
>
>
>>
>> Thanks for the pointers!
>>
>> - Les
>>
>

Re: Preparing for our first release

Posted by Les Hazlewood <lh...@apache.org>.

Nice!  Glad to see this finally up :)

Thanks Kalle!

- Les

On Wed, Feb 10, 2010 at 1:18 AM, Kalle Korhonen
<ka...@gmail.com> wrote:
> On Tue, Feb 9, 2010 at 2:34 PM, Kalle Korhonen
> <ka...@gmail.com> wrote:
>> On Tue, Feb 9, 2010 at 2:30 PM, Les Hazlewood <lh...@apache.org> wrote:
>>> I'm very much in favor of aggregate JavaDocs - as an end-user, I would
>>> hate to have to go to multiple locations to view core JavaDoc vs web
>>> JavaDoc vs Spring-support JavaDoc, etc...
>> Agree. I'm going to put it back and try deploying the site.
>
> FYI: http://incubator.apache.org/shiro/site/ (but I'll change it to
> deploy to /${project.version} and /latest for snapshots).
>
> Kalle
>
>>> On Tue, Feb 9, 2010 at 5:15 PM, Kalle Korhonen
>>> <ka...@gmail.com> wrote:
>>>> Aggregate javadocs or not for the site? Les, at r788750 you had
>>>> commented out the reporting section including aggregate javadoc
>>>> configuration with comment:
>>>> "Ugraded to apache parent pom version 6.  Removed retroweaver
>>>> dependencies as Shiro 1.0+ will use JDK 1.5 as its base requirement
>>>> per email thread..."
>>>>
>>>> Was that on purpose?
>>>>
>>>> Kalle
>>>>
>>>>
>>>> On Tue, Feb 9, 2010 at 10:01 AM, Les Hazlewood <lh...@apache.org> wrote:
>>>>> I'm not sure exactly - I assumed it was useful only because it is
>>>>> incredibly useful for me :)
>>>>>
>>>>> For example, I find this very useful:
>>>>>
>>>>> http://www.springsource.org/documentation
>>>>>
>>>>> Based on that page, I know exactly where to go for documentation
>>>>> related to the particular version of Spring I'm using.
>>>>>
>>>>> My .02,
>>>>>
>>>>> Les
>>>>>
>>>>> On Tue, Feb 9, 2010 at 12:57 PM, Kalle Korhonen
>>>>> <ka...@gmail.com> wrote:
>>>>>> On Tue, Feb 9, 2010 at 9:49 AM, Les Hazlewood <lh...@apache.org> wrote:
>>>>>>> The way we did this for JSecurity was to publish each release's
>>>>>>> documentation to its own version specific directory.  Then I'd use a
>>>>>>> symlink to point to the 'current' version and/or snapshot. I.E.:
>>>>>>>
>>>>>>> http://shiro.apache.org/site/current/api
>>>>>>>
>>>>>>> and in the site directory, you'd have the following directories:
>>>>>>>
>>>>>>> 0.9.2
>>>>>>> 1.0.0
>>>>>>> 1.0.3
>>>>>>> 1.0.4-SNAPSHOT
>>>>>>>
>>>>>>> and each time we published something important, we changed 'current'
>>>>>>> symlink to point to the latest release - it was really nice.  Can we
>>>>>>> still do this?  Maybe not, but I'm just checking.  Will this work?
>>>>>>
>>>>>> Yeah, we could. The symlink probably needs to be created manually (as
>>>>>> opposed to as part of site-deploy.. though with sufficient coding,
>>>>>> anything's possible). Do you have any idea how the users felt about -
>>>>>> were the older docs used at all, was there confusion about which docs
>>>>>> they are browsing etc?
>>>>>>
>>>>>> Kalle
>>>>>>
>>>>>>
>>>>>>> On Tue, Feb 9, 2010 at 12:36 PM, Kalle Korhonen
>>>>>>> <ka...@gmail.com> wrote:
>>>>>>>> Thanks to Brian for detailed instructions. I'm familiar with staged
>>>>>>>> releases and Nexus so we should be able to get this done. I assume I'm
>>>>>>>> going to cut the release when the time comes unless somebody else
>>>>>>>> steps up :)
>>>>>>>>
>>>>>>>> Les, as Brian noted site's somewhat separate from the release but by
>>>>>>>> default it's published at release time. Basically we have two options,
>>>>>>>> either we publish just snapshots of the site (i.e. exactly one site
>>>>>>>> url) or a site per release (i.e. site/1.0.0) and single url for
>>>>>>>> snapshots, the latter can be achieved with profiles. Multiple archived
>>>>>>>> and released sites could be useful (but also confusing) for users when
>>>>>>>> we have multiple releases available, but just for simplicity's sake
>>>>>>>> I'd go with a single site url at first. The javadocs are in any case
>>>>>>>> deployed per released version.
>>>>>>>>
>>>>>>>> Kalle
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, Feb 9, 2010 at 7:49 AM, Brian Demers <br...@gmail.com> wrote:
>>>>>>>>> Hey Les,
>>>>>>>>>
>>>>>>>>> On Tue, Feb 9, 2010 at 10:32 AM, Les Hazlewood <lh...@apache.org>wrote:
>>>>>>>>>
>>>>>>>>>> Hi Brian,
>>>>>>>>>>
>>>>>>>>>> > To get everything setup for a staging repository
>>>>>>>>>> > Create a sub task under:
>>>>>>>>>> https://issues.apache.org/jira/browse/INFRA-1896
>>>>>>>>>>
>>>>>>>>>> Done:
>>>>>>>>>>
>>>>>>>>>> https://issues.apache.org/jira/browse/INFRA-2488
>>>>>>>>>>
>>>>>>>>>> > After the deploy you need to close the staging repo, and promote it
>>>>>>>>>>
>>>>>>>>>> What do you mean by close the staging repo?  Just ensure that the team
>>>>>>>>>> does not deploy to staging to prevent overwrites?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> A single maven deploy is a bunch of stateless deploys so there is no way to
>>>>>>>>> know when maven is done deploying all the artifacts.  So after you do a
>>>>>>>>> deploy you need to tell Nexus you are finished.  This puts the repository in
>>>>>>>>> a read-only mode
>>>>>>>>>
>>>>>>>>> You could do this all from a maven plugin (but personally I like the UI for
>>>>>>>>> this):
>>>>>>>>> http://plugins.sonatype.org/nexus-maven-plugin/usage-staging.html
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Also, once the artifacts are in staging, how is promotion done in
>>>>>>>>>> Nexus?  I mean, let's say that the community votes to approve the
>>>>>>>>>> release.  How do you propagate those voted-upon artifacts from staging
>>>>>>>>>> to the release repo?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The actual promoting is also just a couple clicks (or the plugin listed
>>>>>>>>> above)
>>>>>>>>> Upon promotion all the artifacts are moved into the release repository. (and
>>>>>>>>> corresponding metadata is merged i.e. maven-metadata.xml)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Thanks for the pointers!
>>>>>>>>>>
>>>>>>>>>> - Les
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

Re: Preparing for our first release

Posted by Les Hazlewood <lh...@apache.org>.

P.S.  Can you please let me know when you've had the chance to put the
symlinks are up?  I'd like to start changing the wiki's in-line
documentation to reference the Shiro public apidocs instead of the old
JSecurity ones.  There's no hurry - this is more of a reminder for me
than anything else.

On Wed, Feb 10, 2010 at 1:18 AM, Kalle Korhonen
<ka...@gmail.com> wrote:
> On Tue, Feb 9, 2010 at 2:34 PM, Kalle Korhonen
> <ka...@gmail.com> wrote:
>> On Tue, Feb 9, 2010 at 2:30 PM, Les Hazlewood <lh...@apache.org> wrote:
>>> I'm very much in favor of aggregate JavaDocs - as an end-user, I would
>>> hate to have to go to multiple locations to view core JavaDoc vs web
>>> JavaDoc vs Spring-support JavaDoc, etc...
>> Agree. I'm going to put it back and try deploying the site.
>
> FYI: http://incubator.apache.org/shiro/site/ (but I'll change it to
> deploy to /${project.version} and /latest for snapshots).
>
> Kalle
>
>>> On Tue, Feb 9, 2010 at 5:15 PM, Kalle Korhonen
>>> <ka...@gmail.com> wrote:
>>>> Aggregate javadocs or not for the site? Les, at r788750 you had
>>>> commented out the reporting section including aggregate javadoc
>>>> configuration with comment:
>>>> "Ugraded to apache parent pom version 6.  Removed retroweaver
>>>> dependencies as Shiro 1.0+ will use JDK 1.5 as its base requirement
>>>> per email thread..."
>>>>
>>>> Was that on purpose?
>>>>
>>>> Kalle
>>>>
>>>>
>>>> On Tue, Feb 9, 2010 at 10:01 AM, Les Hazlewood <lh...@apache.org> wrote:
>>>>> I'm not sure exactly - I assumed it was useful only because it is
>>>>> incredibly useful for me :)
>>>>>
>>>>> For example, I find this very useful:
>>>>>
>>>>> http://www.springsource.org/documentation
>>>>>
>>>>> Based on that page, I know exactly where to go for documentation
>>>>> related to the particular version of Spring I'm using.
>>>>>
>>>>> My .02,
>>>>>
>>>>> Les
>>>>>
>>>>> On Tue, Feb 9, 2010 at 12:57 PM, Kalle Korhonen
>>>>> <ka...@gmail.com> wrote:
>>>>>> On Tue, Feb 9, 2010 at 9:49 AM, Les Hazlewood <lh...@apache.org> wrote:
>>>>>>> The way we did this for JSecurity was to publish each release's
>>>>>>> documentation to its own version specific directory.  Then I'd use a
>>>>>>> symlink to point to the 'current' version and/or snapshot. I.E.:
>>>>>>>
>>>>>>> http://shiro.apache.org/site/current/api
>>>>>>>
>>>>>>> and in the site directory, you'd have the following directories:
>>>>>>>
>>>>>>> 0.9.2
>>>>>>> 1.0.0
>>>>>>> 1.0.3
>>>>>>> 1.0.4-SNAPSHOT
>>>>>>>
>>>>>>> and each time we published something important, we changed 'current'
>>>>>>> symlink to point to the latest release - it was really nice.  Can we
>>>>>>> still do this?  Maybe not, but I'm just checking.  Will this work?
>>>>>>
>>>>>> Yeah, we could. The symlink probably needs to be created manually (as
>>>>>> opposed to as part of site-deploy.. though with sufficient coding,
>>>>>> anything's possible). Do you have any idea how the users felt about -
>>>>>> were the older docs used at all, was there confusion about which docs
>>>>>> they are browsing etc?
>>>>>>
>>>>>> Kalle
>>>>>>
>>>>>>
>>>>>>> On Tue, Feb 9, 2010 at 12:36 PM, Kalle Korhonen
>>>>>>> <ka...@gmail.com> wrote:
>>>>>>>> Thanks to Brian for detailed instructions. I'm familiar with staged
>>>>>>>> releases and Nexus so we should be able to get this done. I assume I'm
>>>>>>>> going to cut the release when the time comes unless somebody else
>>>>>>>> steps up :)
>>>>>>>>
>>>>>>>> Les, as Brian noted site's somewhat separate from the release but by
>>>>>>>> default it's published at release time. Basically we have two options,
>>>>>>>> either we publish just snapshots of the site (i.e. exactly one site
>>>>>>>> url) or a site per release (i.e. site/1.0.0) and single url for
>>>>>>>> snapshots, the latter can be achieved with profiles. Multiple archived
>>>>>>>> and released sites could be useful (but also confusing) for users when
>>>>>>>> we have multiple releases available, but just for simplicity's sake
>>>>>>>> I'd go with a single site url at first. The javadocs are in any case
>>>>>>>> deployed per released version.
>>>>>>>>
>>>>>>>> Kalle
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, Feb 9, 2010 at 7:49 AM, Brian Demers <br...@gmail.com> wrote:
>>>>>>>>> Hey Les,
>>>>>>>>>
>>>>>>>>> On Tue, Feb 9, 2010 at 10:32 AM, Les Hazlewood <lh...@apache.org>wrote:
>>>>>>>>>
>>>>>>>>>> Hi Brian,
>>>>>>>>>>
>>>>>>>>>> > To get everything setup for a staging repository
>>>>>>>>>> > Create a sub task under:
>>>>>>>>>> https://issues.apache.org/jira/browse/INFRA-1896
>>>>>>>>>>
>>>>>>>>>> Done:
>>>>>>>>>>
>>>>>>>>>> https://issues.apache.org/jira/browse/INFRA-2488
>>>>>>>>>>
>>>>>>>>>> > After the deploy you need to close the staging repo, and promote it
>>>>>>>>>>
>>>>>>>>>> What do you mean by close the staging repo?  Just ensure that the team
>>>>>>>>>> does not deploy to staging to prevent overwrites?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> A single maven deploy is a bunch of stateless deploys so there is no way to
>>>>>>>>> know when maven is done deploying all the artifacts.  So after you do a
>>>>>>>>> deploy you need to tell Nexus you are finished.  This puts the repository in
>>>>>>>>> a read-only mode
>>>>>>>>>
>>>>>>>>> You could do this all from a maven plugin (but personally I like the UI for
>>>>>>>>> this):
>>>>>>>>> http://plugins.sonatype.org/nexus-maven-plugin/usage-staging.html
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Also, once the artifacts are in staging, how is promotion done in
>>>>>>>>>> Nexus?  I mean, let's say that the community votes to approve the
>>>>>>>>>> release.  How do you propagate those voted-upon artifacts from staging
>>>>>>>>>> to the release repo?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The actual promoting is also just a couple clicks (or the plugin listed
>>>>>>>>> above)
>>>>>>>>> Upon promotion all the artifacts are moved into the release repository. (and
>>>>>>>>> corresponding metadata is merged i.e. maven-metadata.xml)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Thanks for the pointers!
>>>>>>>>>>
>>>>>>>>>> - Les
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

Re: Preparing for our first release

Posted by Kalle Korhonen <ka...@gmail.com>.

On Tue, Feb 9, 2010 at 2:34 PM, Kalle Korhonen
<ka...@gmail.com> wrote:
> On Tue, Feb 9, 2010 at 2:30 PM, Les Hazlewood <lh...@apache.org> wrote:
>> I'm very much in favor of aggregate JavaDocs - as an end-user, I would
>> hate to have to go to multiple locations to view core JavaDoc vs web
>> JavaDoc vs Spring-support JavaDoc, etc...
> Agree. I'm going to put it back and try deploying the site.

FYI: http://incubator.apache.org/shiro/site/ (but I'll change it to
deploy to /${project.version} and /latest for snapshots).

Kalle

>> On Tue, Feb 9, 2010 at 5:15 PM, Kalle Korhonen
>> <ka...@gmail.com> wrote:
>>> Aggregate javadocs or not for the site? Les, at r788750 you had
>>> commented out the reporting section including aggregate javadoc
>>> configuration with comment:
>>> "Ugraded to apache parent pom version 6.  Removed retroweaver
>>> dependencies as Shiro 1.0+ will use JDK 1.5 as its base requirement
>>> per email thread..."
>>>
>>> Was that on purpose?
>>>
>>> Kalle
>>>
>>>
>>> On Tue, Feb 9, 2010 at 10:01 AM, Les Hazlewood <lh...@apache.org> wrote:
>>>> I'm not sure exactly - I assumed it was useful only because it is
>>>> incredibly useful for me :)
>>>>
>>>> For example, I find this very useful:
>>>>
>>>> http://www.springsource.org/documentation
>>>>
>>>> Based on that page, I know exactly where to go for documentation
>>>> related to the particular version of Spring I'm using.
>>>>
>>>> My .02,
>>>>
>>>> Les
>>>>
>>>> On Tue, Feb 9, 2010 at 12:57 PM, Kalle Korhonen
>>>> <ka...@gmail.com> wrote:
>>>>> On Tue, Feb 9, 2010 at 9:49 AM, Les Hazlewood <lh...@apache.org> wrote:
>>>>>> The way we did this for JSecurity was to publish each release's
>>>>>> documentation to its own version specific directory.  Then I'd use a
>>>>>> symlink to point to the 'current' version and/or snapshot. I.E.:
>>>>>>
>>>>>> http://shiro.apache.org/site/current/api
>>>>>>
>>>>>> and in the site directory, you'd have the following directories:
>>>>>>
>>>>>> 0.9.2
>>>>>> 1.0.0
>>>>>> 1.0.3
>>>>>> 1.0.4-SNAPSHOT
>>>>>>
>>>>>> and each time we published something important, we changed 'current'
>>>>>> symlink to point to the latest release - it was really nice.  Can we
>>>>>> still do this?  Maybe not, but I'm just checking.  Will this work?
>>>>>
>>>>> Yeah, we could. The symlink probably needs to be created manually (as
>>>>> opposed to as part of site-deploy.. though with sufficient coding,
>>>>> anything's possible). Do you have any idea how the users felt about -
>>>>> were the older docs used at all, was there confusion about which docs
>>>>> they are browsing etc?
>>>>>
>>>>> Kalle
>>>>>
>>>>>
>>>>>> On Tue, Feb 9, 2010 at 12:36 PM, Kalle Korhonen
>>>>>> <ka...@gmail.com> wrote:
>>>>>>> Thanks to Brian for detailed instructions. I'm familiar with staged
>>>>>>> releases and Nexus so we should be able to get this done. I assume I'm
>>>>>>> going to cut the release when the time comes unless somebody else
>>>>>>> steps up :)
>>>>>>>
>>>>>>> Les, as Brian noted site's somewhat separate from the release but by
>>>>>>> default it's published at release time. Basically we have two options,
>>>>>>> either we publish just snapshots of the site (i.e. exactly one site
>>>>>>> url) or a site per release (i.e. site/1.0.0) and single url for
>>>>>>> snapshots, the latter can be achieved with profiles. Multiple archived
>>>>>>> and released sites could be useful (but also confusing) for users when
>>>>>>> we have multiple releases available, but just for simplicity's sake
>>>>>>> I'd go with a single site url at first. The javadocs are in any case
>>>>>>> deployed per released version.
>>>>>>>
>>>>>>> Kalle
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Feb 9, 2010 at 7:49 AM, Brian Demers <br...@gmail.com> wrote:
>>>>>>>> Hey Les,
>>>>>>>>
>>>>>>>> On Tue, Feb 9, 2010 at 10:32 AM, Les Hazlewood <lh...@apache.org>wrote:
>>>>>>>>
>>>>>>>>> Hi Brian,
>>>>>>>>>
>>>>>>>>> > To get everything setup for a staging repository
>>>>>>>>> > Create a sub task under:
>>>>>>>>> https://issues.apache.org/jira/browse/INFRA-1896
>>>>>>>>>
>>>>>>>>> Done:
>>>>>>>>>
>>>>>>>>> https://issues.apache.org/jira/browse/INFRA-2488
>>>>>>>>>
>>>>>>>>> > After the deploy you need to close the staging repo, and promote it
>>>>>>>>>
>>>>>>>>> What do you mean by close the staging repo?  Just ensure that the team
>>>>>>>>> does not deploy to staging to prevent overwrites?
>>>>>>>>>
>>>>>>>>
>>>>>>>> A single maven deploy is a bunch of stateless deploys so there is no way to
>>>>>>>> know when maven is done deploying all the artifacts.  So after you do a
>>>>>>>> deploy you need to tell Nexus you are finished.  This puts the repository in
>>>>>>>> a read-only mode
>>>>>>>>
>>>>>>>> You could do this all from a maven plugin (but personally I like the UI for
>>>>>>>> this):
>>>>>>>> http://plugins.sonatype.org/nexus-maven-plugin/usage-staging.html
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Also, once the artifacts are in staging, how is promotion done in
>>>>>>>>> Nexus?  I mean, let's say that the community votes to approve the
>>>>>>>>> release.  How do you propagate those voted-upon artifacts from staging
>>>>>>>>> to the release repo?
>>>>>>>>>
>>>>>>>>
>>>>>>>> The actual promoting is also just a couple clicks (or the plugin listed
>>>>>>>> above)
>>>>>>>> Upon promotion all the artifacts are moved into the release repository. (and
>>>>>>>> corresponding metadata is merged i.e. maven-metadata.xml)
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thanks for the pointers!
>>>>>>>>>
>>>>>>>>> - Les
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

Re: Preparing for our first release

Posted by Kalle Korhonen <ka...@gmail.com>.

On Tue, Feb 9, 2010 at 2:30 PM, Les Hazlewood <lh...@apache.org> wrote:
> I think I did that because of the increased build time, but I can't
> remember exactly.

Yea it takes a long time but only if you build the site.

> I'm very much in favor of aggregate JavaDocs - as an end-user, I would
> hate to have to go to multiple locations to view core JavaDoc vs web
> JavaDoc vs Spring-support JavaDoc, etc...

Agree. I'm going to put it back and try deploying the site.

Kalle


> On Tue, Feb 9, 2010 at 5:15 PM, Kalle Korhonen
> <ka...@gmail.com> wrote:
>> Aggregate javadocs or not for the site? Les, at r788750 you had
>> commented out the reporting section including aggregate javadoc
>> configuration with comment:
>> "Ugraded to apache parent pom version 6.  Removed retroweaver
>> dependencies as Shiro 1.0+ will use JDK 1.5 as its base requirement
>> per email thread..."
>>
>> Was that on purpose?
>>
>> Kalle
>>
>>
>> On Tue, Feb 9, 2010 at 10:01 AM, Les Hazlewood <lh...@apache.org> wrote:
>>> I'm not sure exactly - I assumed it was useful only because it is
>>> incredibly useful for me :)
>>>
>>> For example, I find this very useful:
>>>
>>> http://www.springsource.org/documentation
>>>
>>> Based on that page, I know exactly where to go for documentation
>>> related to the particular version of Spring I'm using.
>>>
>>> My .02,
>>>
>>> Les
>>>
>>> On Tue, Feb 9, 2010 at 12:57 PM, Kalle Korhonen
>>> <ka...@gmail.com> wrote:
>>>> On Tue, Feb 9, 2010 at 9:49 AM, Les Hazlewood <lh...@apache.org> wrote:
>>>>> The way we did this for JSecurity was to publish each release's
>>>>> documentation to its own version specific directory.  Then I'd use a
>>>>> symlink to point to the 'current' version and/or snapshot. I.E.:
>>>>>
>>>>> http://shiro.apache.org/site/current/api
>>>>>
>>>>> and in the site directory, you'd have the following directories:
>>>>>
>>>>> 0.9.2
>>>>> 1.0.0
>>>>> 1.0.3
>>>>> 1.0.4-SNAPSHOT
>>>>>
>>>>> and each time we published something important, we changed 'current'
>>>>> symlink to point to the latest release - it was really nice.  Can we
>>>>> still do this?  Maybe not, but I'm just checking.  Will this work?
>>>>
>>>> Yeah, we could. The symlink probably needs to be created manually (as
>>>> opposed to as part of site-deploy.. though with sufficient coding,
>>>> anything's possible). Do you have any idea how the users felt about -
>>>> were the older docs used at all, was there confusion about which docs
>>>> they are browsing etc?
>>>>
>>>> Kalle
>>>>
>>>>
>>>>> On Tue, Feb 9, 2010 at 12:36 PM, Kalle Korhonen
>>>>> <ka...@gmail.com> wrote:
>>>>>> Thanks to Brian for detailed instructions. I'm familiar with staged
>>>>>> releases and Nexus so we should be able to get this done. I assume I'm
>>>>>> going to cut the release when the time comes unless somebody else
>>>>>> steps up :)
>>>>>>
>>>>>> Les, as Brian noted site's somewhat separate from the release but by
>>>>>> default it's published at release time. Basically we have two options,
>>>>>> either we publish just snapshots of the site (i.e. exactly one site
>>>>>> url) or a site per release (i.e. site/1.0.0) and single url for
>>>>>> snapshots, the latter can be achieved with profiles. Multiple archived
>>>>>> and released sites could be useful (but also confusing) for users when
>>>>>> we have multiple releases available, but just for simplicity's sake
>>>>>> I'd go with a single site url at first. The javadocs are in any case
>>>>>> deployed per released version.
>>>>>>
>>>>>> Kalle
>>>>>>
>>>>>>
>>>>>> On Tue, Feb 9, 2010 at 7:49 AM, Brian Demers <br...@gmail.com> wrote:
>>>>>>> Hey Les,
>>>>>>>
>>>>>>> On Tue, Feb 9, 2010 at 10:32 AM, Les Hazlewood <lh...@apache.org>wrote:
>>>>>>>
>>>>>>>> Hi Brian,
>>>>>>>>
>>>>>>>> > To get everything setup for a staging repository
>>>>>>>> > Create a sub task under:
>>>>>>>> https://issues.apache.org/jira/browse/INFRA-1896
>>>>>>>>
>>>>>>>> Done:
>>>>>>>>
>>>>>>>> https://issues.apache.org/jira/browse/INFRA-2488
>>>>>>>>
>>>>>>>> > After the deploy you need to close the staging repo, and promote it
>>>>>>>>
>>>>>>>> What do you mean by close the staging repo?  Just ensure that the team
>>>>>>>> does not deploy to staging to prevent overwrites?
>>>>>>>>
>>>>>>>
>>>>>>> A single maven deploy is a bunch of stateless deploys so there is no way to
>>>>>>> know when maven is done deploying all the artifacts.  So after you do a
>>>>>>> deploy you need to tell Nexus you are finished.  This puts the repository in
>>>>>>> a read-only mode
>>>>>>>
>>>>>>> You could do this all from a maven plugin (but personally I like the UI for
>>>>>>> this):
>>>>>>> http://plugins.sonatype.org/nexus-maven-plugin/usage-staging.html
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Also, once the artifacts are in staging, how is promotion done in
>>>>>>>> Nexus?  I mean, let's say that the community votes to approve the
>>>>>>>> release.  How do you propagate those voted-upon artifacts from staging
>>>>>>>> to the release repo?
>>>>>>>>
>>>>>>>
>>>>>>> The actual promoting is also just a couple clicks (or the plugin listed
>>>>>>> above)
>>>>>>> Upon promotion all the artifacts are moved into the release repository. (and
>>>>>>> corresponding metadata is merged i.e. maven-metadata.xml)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Thanks for the pointers!
>>>>>>>>
>>>>>>>> - Les
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

Re: Preparing for our first release

Posted by Les Hazlewood <lh...@apache.org>.

I think I did that because of the increased build time, but I can't
remember exactly.

I'm very much in favor of aggregate JavaDocs - as an end-user, I would
hate to have to go to multiple locations to view core JavaDoc vs web
JavaDoc vs Spring-support JavaDoc, etc...

- Les

On Tue, Feb 9, 2010 at 5:15 PM, Kalle Korhonen
<ka...@gmail.com> wrote:
> Aggregate javadocs or not for the site? Les, at r788750 you had
> commented out the reporting section including aggregate javadoc
> configuration with comment:
> "Ugraded to apache parent pom version 6.  Removed retroweaver
> dependencies as Shiro 1.0+ will use JDK 1.5 as its base requirement
> per email thread..."
>
> Was that on purpose?
>
> Kalle
>
>
> On Tue, Feb 9, 2010 at 10:01 AM, Les Hazlewood <lh...@apache.org> wrote:
>> I'm not sure exactly - I assumed it was useful only because it is
>> incredibly useful for me :)
>>
>> For example, I find this very useful:
>>
>> http://www.springsource.org/documentation
>>
>> Based on that page, I know exactly where to go for documentation
>> related to the particular version of Spring I'm using.
>>
>> My .02,
>>
>> Les
>>
>> On Tue, Feb 9, 2010 at 12:57 PM, Kalle Korhonen
>> <ka...@gmail.com> wrote:
>>> On Tue, Feb 9, 2010 at 9:49 AM, Les Hazlewood <lh...@apache.org> wrote:
>>>> The way we did this for JSecurity was to publish each release's
>>>> documentation to its own version specific directory.  Then I'd use a
>>>> symlink to point to the 'current' version and/or snapshot. I.E.:
>>>>
>>>> http://shiro.apache.org/site/current/api
>>>>
>>>> and in the site directory, you'd have the following directories:
>>>>
>>>> 0.9.2
>>>> 1.0.0
>>>> 1.0.3
>>>> 1.0.4-SNAPSHOT
>>>>
>>>> and each time we published something important, we changed 'current'
>>>> symlink to point to the latest release - it was really nice.  Can we
>>>> still do this?  Maybe not, but I'm just checking.  Will this work?
>>>
>>> Yeah, we could. The symlink probably needs to be created manually (as
>>> opposed to as part of site-deploy.. though with sufficient coding,
>>> anything's possible). Do you have any idea how the users felt about -
>>> were the older docs used at all, was there confusion about which docs
>>> they are browsing etc?
>>>
>>> Kalle
>>>
>>>
>>>> On Tue, Feb 9, 2010 at 12:36 PM, Kalle Korhonen
>>>> <ka...@gmail.com> wrote:
>>>>> Thanks to Brian for detailed instructions. I'm familiar with staged
>>>>> releases and Nexus so we should be able to get this done. I assume I'm
>>>>> going to cut the release when the time comes unless somebody else
>>>>> steps up :)
>>>>>
>>>>> Les, as Brian noted site's somewhat separate from the release but by
>>>>> default it's published at release time. Basically we have two options,
>>>>> either we publish just snapshots of the site (i.e. exactly one site
>>>>> url) or a site per release (i.e. site/1.0.0) and single url for
>>>>> snapshots, the latter can be achieved with profiles. Multiple archived
>>>>> and released sites could be useful (but also confusing) for users when
>>>>> we have multiple releases available, but just for simplicity's sake
>>>>> I'd go with a single site url at first. The javadocs are in any case
>>>>> deployed per released version.
>>>>>
>>>>> Kalle
>>>>>
>>>>>
>>>>> On Tue, Feb 9, 2010 at 7:49 AM, Brian Demers <br...@gmail.com> wrote:
>>>>>> Hey Les,
>>>>>>
>>>>>> On Tue, Feb 9, 2010 at 10:32 AM, Les Hazlewood <lh...@apache.org>wrote:
>>>>>>
>>>>>>> Hi Brian,
>>>>>>>
>>>>>>> > To get everything setup for a staging repository
>>>>>>> > Create a sub task under:
>>>>>>> https://issues.apache.org/jira/browse/INFRA-1896
>>>>>>>
>>>>>>> Done:
>>>>>>>
>>>>>>> https://issues.apache.org/jira/browse/INFRA-2488
>>>>>>>
>>>>>>> > After the deploy you need to close the staging repo, and promote it
>>>>>>>
>>>>>>> What do you mean by close the staging repo?  Just ensure that the team
>>>>>>> does not deploy to staging to prevent overwrites?
>>>>>>>
>>>>>>
>>>>>> A single maven deploy is a bunch of stateless deploys so there is no way to
>>>>>> know when maven is done deploying all the artifacts.  So after you do a
>>>>>> deploy you need to tell Nexus you are finished.  This puts the repository in
>>>>>> a read-only mode
>>>>>>
>>>>>> You could do this all from a maven plugin (but personally I like the UI for
>>>>>> this):
>>>>>> http://plugins.sonatype.org/nexus-maven-plugin/usage-staging.html
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Also, once the artifacts are in staging, how is promotion done in
>>>>>>> Nexus?  I mean, let's say that the community votes to approve the
>>>>>>> release.  How do you propagate those voted-upon artifacts from staging
>>>>>>> to the release repo?
>>>>>>>
>>>>>>
>>>>>> The actual promoting is also just a couple clicks (or the plugin listed
>>>>>> above)
>>>>>> Upon promotion all the artifacts are moved into the release repository. (and
>>>>>> corresponding metadata is merged i.e. maven-metadata.xml)
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Thanks for the pointers!
>>>>>>>
>>>>>>> - Les
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

Re: Preparing for our first release

Posted by Kalle Korhonen <ka...@gmail.com>.

Aggregate javadocs or not for the site? Les, at r788750 you had
commented out the reporting section including aggregate javadoc
configuration with comment:
"Ugraded to apache parent pom version 6.  Removed retroweaver
dependencies as Shiro 1.0+ will use JDK 1.5 as its base requirement
per email thread..."

Was that on purpose?

Kalle


On Tue, Feb 9, 2010 at 10:01 AM, Les Hazlewood <lh...@apache.org> wrote:
> I'm not sure exactly - I assumed it was useful only because it is
> incredibly useful for me :)
>
> For example, I find this very useful:
>
> http://www.springsource.org/documentation
>
> Based on that page, I know exactly where to go for documentation
> related to the particular version of Spring I'm using.
>
> My .02,
>
> Les
>
> On Tue, Feb 9, 2010 at 12:57 PM, Kalle Korhonen
> <ka...@gmail.com> wrote:
>> On Tue, Feb 9, 2010 at 9:49 AM, Les Hazlewood <lh...@apache.org> wrote:
>>> The way we did this for JSecurity was to publish each release's
>>> documentation to its own version specific directory.  Then I'd use a
>>> symlink to point to the 'current' version and/or snapshot. I.E.:
>>>
>>> http://shiro.apache.org/site/current/api
>>>
>>> and in the site directory, you'd have the following directories:
>>>
>>> 0.9.2
>>> 1.0.0
>>> 1.0.3
>>> 1.0.4-SNAPSHOT
>>>
>>> and each time we published something important, we changed 'current'
>>> symlink to point to the latest release - it was really nice.  Can we
>>> still do this?  Maybe not, but I'm just checking.  Will this work?
>>
>> Yeah, we could. The symlink probably needs to be created manually (as
>> opposed to as part of site-deploy.. though with sufficient coding,
>> anything's possible). Do you have any idea how the users felt about -
>> were the older docs used at all, was there confusion about which docs
>> they are browsing etc?
>>
>> Kalle
>>
>>
>>> On Tue, Feb 9, 2010 at 12:36 PM, Kalle Korhonen
>>> <ka...@gmail.com> wrote:
>>>> Thanks to Brian for detailed instructions. I'm familiar with staged
>>>> releases and Nexus so we should be able to get this done. I assume I'm
>>>> going to cut the release when the time comes unless somebody else
>>>> steps up :)
>>>>
>>>> Les, as Brian noted site's somewhat separate from the release but by
>>>> default it's published at release time. Basically we have two options,
>>>> either we publish just snapshots of the site (i.e. exactly one site
>>>> url) or a site per release (i.e. site/1.0.0) and single url for
>>>> snapshots, the latter can be achieved with profiles. Multiple archived
>>>> and released sites could be useful (but also confusing) for users when
>>>> we have multiple releases available, but just for simplicity's sake
>>>> I'd go with a single site url at first. The javadocs are in any case
>>>> deployed per released version.
>>>>
>>>> Kalle
>>>>
>>>>
>>>> On Tue, Feb 9, 2010 at 7:49 AM, Brian Demers <br...@gmail.com> wrote:
>>>>> Hey Les,
>>>>>
>>>>> On Tue, Feb 9, 2010 at 10:32 AM, Les Hazlewood <lh...@apache.org>wrote:
>>>>>
>>>>>> Hi Brian,
>>>>>>
>>>>>> > To get everything setup for a staging repository
>>>>>> > Create a sub task under:
>>>>>> https://issues.apache.org/jira/browse/INFRA-1896
>>>>>>
>>>>>> Done:
>>>>>>
>>>>>> https://issues.apache.org/jira/browse/INFRA-2488
>>>>>>
>>>>>> > After the deploy you need to close the staging repo, and promote it
>>>>>>
>>>>>> What do you mean by close the staging repo?  Just ensure that the team
>>>>>> does not deploy to staging to prevent overwrites?
>>>>>>
>>>>>
>>>>> A single maven deploy is a bunch of stateless deploys so there is no way to
>>>>> know when maven is done deploying all the artifacts.  So after you do a
>>>>> deploy you need to tell Nexus you are finished.  This puts the repository in
>>>>> a read-only mode
>>>>>
>>>>> You could do this all from a maven plugin (but personally I like the UI for
>>>>> this):
>>>>> http://plugins.sonatype.org/nexus-maven-plugin/usage-staging.html
>>>>>
>>>>>
>>>>>>
>>>>>> Also, once the artifacts are in staging, how is promotion done in
>>>>>> Nexus?  I mean, let's say that the community votes to approve the
>>>>>> release.  How do you propagate those voted-upon artifacts from staging
>>>>>> to the release repo?
>>>>>>
>>>>>
>>>>> The actual promoting is also just a couple clicks (or the plugin listed
>>>>> above)
>>>>> Upon promotion all the artifacts are moved into the release repository. (and
>>>>> corresponding metadata is merged i.e. maven-metadata.xml)
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> Thanks for the pointers!
>>>>>>
>>>>>> - Les
>>>>>>
>>>>>
>>>>
>>>
>>
>

Re: Preparing for our first release

Posted by Les Hazlewood <lh...@apache.org>.

I'm not sure exactly - I assumed it was useful only because it is
incredibly useful for me :)

For example, I find this very useful:

http://www.springsource.org/documentation

Based on that page, I know exactly where to go for documentation
related to the particular version of Spring I'm using.

My .02,

Les

On Tue, Feb 9, 2010 at 12:57 PM, Kalle Korhonen
<ka...@gmail.com> wrote:
> On Tue, Feb 9, 2010 at 9:49 AM, Les Hazlewood <lh...@apache.org> wrote:
>> The way we did this for JSecurity was to publish each release's
>> documentation to its own version specific directory.  Then I'd use a
>> symlink to point to the 'current' version and/or snapshot. I.E.:
>>
>> http://shiro.apache.org/site/current/api
>>
>> and in the site directory, you'd have the following directories:
>>
>> 0.9.2
>> 1.0.0
>> 1.0.3
>> 1.0.4-SNAPSHOT
>>
>> and each time we published something important, we changed 'current'
>> symlink to point to the latest release - it was really nice.  Can we
>> still do this?  Maybe not, but I'm just checking.  Will this work?
>
> Yeah, we could. The symlink probably needs to be created manually (as
> opposed to as part of site-deploy.. though with sufficient coding,
> anything's possible). Do you have any idea how the users felt about -
> were the older docs used at all, was there confusion about which docs
> they are browsing etc?
>
> Kalle
>
>
>> On Tue, Feb 9, 2010 at 12:36 PM, Kalle Korhonen
>> <ka...@gmail.com> wrote:
>>> Thanks to Brian for detailed instructions. I'm familiar with staged
>>> releases and Nexus so we should be able to get this done. I assume I'm
>>> going to cut the release when the time comes unless somebody else
>>> steps up :)
>>>
>>> Les, as Brian noted site's somewhat separate from the release but by
>>> default it's published at release time. Basically we have two options,
>>> either we publish just snapshots of the site (i.e. exactly one site
>>> url) or a site per release (i.e. site/1.0.0) and single url for
>>> snapshots, the latter can be achieved with profiles. Multiple archived
>>> and released sites could be useful (but also confusing) for users when
>>> we have multiple releases available, but just for simplicity's sake
>>> I'd go with a single site url at first. The javadocs are in any case
>>> deployed per released version.
>>>
>>> Kalle
>>>
>>>
>>> On Tue, Feb 9, 2010 at 7:49 AM, Brian Demers <br...@gmail.com> wrote:
>>>> Hey Les,
>>>>
>>>> On Tue, Feb 9, 2010 at 10:32 AM, Les Hazlewood <lh...@apache.org>wrote:
>>>>
>>>>> Hi Brian,
>>>>>
>>>>> > To get everything setup for a staging repository
>>>>> > Create a sub task under:
>>>>> https://issues.apache.org/jira/browse/INFRA-1896
>>>>>
>>>>> Done:
>>>>>
>>>>> https://issues.apache.org/jira/browse/INFRA-2488
>>>>>
>>>>> > After the deploy you need to close the staging repo, and promote it
>>>>>
>>>>> What do you mean by close the staging repo?  Just ensure that the team
>>>>> does not deploy to staging to prevent overwrites?
>>>>>
>>>>
>>>> A single maven deploy is a bunch of stateless deploys so there is no way to
>>>> know when maven is done deploying all the artifacts.  So after you do a
>>>> deploy you need to tell Nexus you are finished.  This puts the repository in
>>>> a read-only mode
>>>>
>>>> You could do this all from a maven plugin (but personally I like the UI for
>>>> this):
>>>> http://plugins.sonatype.org/nexus-maven-plugin/usage-staging.html
>>>>
>>>>
>>>>>
>>>>> Also, once the artifacts are in staging, how is promotion done in
>>>>> Nexus?  I mean, let's say that the community votes to approve the
>>>>> release.  How do you propagate those voted-upon artifacts from staging
>>>>> to the release repo?
>>>>>
>>>>
>>>> The actual promoting is also just a couple clicks (or the plugin listed
>>>> above)
>>>> Upon promotion all the artifacts are moved into the release repository. (and
>>>> corresponding metadata is merged i.e. maven-metadata.xml)
>>>>
>>>>
>>>>
>>>>>
>>>>> Thanks for the pointers!
>>>>>
>>>>> - Les
>>>>>
>>>>
>>>
>>
>

Re: Preparing for our first release

Posted by Kalle Korhonen <ka...@gmail.com>.

On Tue, Feb 9, 2010 at 9:49 AM, Les Hazlewood <lh...@apache.org> wrote:
> The way we did this for JSecurity was to publish each release's
> documentation to its own version specific directory.  Then I'd use a
> symlink to point to the 'current' version and/or snapshot. I.E.:
>
> http://shiro.apache.org/site/current/api
>
> and in the site directory, you'd have the following directories:
>
> 0.9.2
> 1.0.0
> 1.0.3
> 1.0.4-SNAPSHOT
>
> and each time we published something important, we changed 'current'
> symlink to point to the latest release - it was really nice.  Can we
> still do this?  Maybe not, but I'm just checking.  Will this work?

Yeah, we could. The symlink probably needs to be created manually (as
opposed to as part of site-deploy.. though with sufficient coding,
anything's possible). Do you have any idea how the users felt about -
were the older docs used at all, was there confusion about which docs
they are browsing etc?

Kalle


> On Tue, Feb 9, 2010 at 12:36 PM, Kalle Korhonen
> <ka...@gmail.com> wrote:
>> Thanks to Brian for detailed instructions. I'm familiar with staged
>> releases and Nexus so we should be able to get this done. I assume I'm
>> going to cut the release when the time comes unless somebody else
>> steps up :)
>>
>> Les, as Brian noted site's somewhat separate from the release but by
>> default it's published at release time. Basically we have two options,
>> either we publish just snapshots of the site (i.e. exactly one site
>> url) or a site per release (i.e. site/1.0.0) and single url for
>> snapshots, the latter can be achieved with profiles. Multiple archived
>> and released sites could be useful (but also confusing) for users when
>> we have multiple releases available, but just for simplicity's sake
>> I'd go with a single site url at first. The javadocs are in any case
>> deployed per released version.
>>
>> Kalle
>>
>>
>> On Tue, Feb 9, 2010 at 7:49 AM, Brian Demers <br...@gmail.com> wrote:
>>> Hey Les,
>>>
>>> On Tue, Feb 9, 2010 at 10:32 AM, Les Hazlewood <lh...@apache.org>wrote:
>>>
>>>> Hi Brian,
>>>>
>>>> > To get everything setup for a staging repository
>>>> > Create a sub task under:
>>>> https://issues.apache.org/jira/browse/INFRA-1896
>>>>
>>>> Done:
>>>>
>>>> https://issues.apache.org/jira/browse/INFRA-2488
>>>>
>>>> > After the deploy you need to close the staging repo, and promote it
>>>>
>>>> What do you mean by close the staging repo?  Just ensure that the team
>>>> does not deploy to staging to prevent overwrites?
>>>>
>>>
>>> A single maven deploy is a bunch of stateless deploys so there is no way to
>>> know when maven is done deploying all the artifacts.  So after you do a
>>> deploy you need to tell Nexus you are finished.  This puts the repository in
>>> a read-only mode
>>>
>>> You could do this all from a maven plugin (but personally I like the UI for
>>> this):
>>> http://plugins.sonatype.org/nexus-maven-plugin/usage-staging.html
>>>
>>>
>>>>
>>>> Also, once the artifacts are in staging, how is promotion done in
>>>> Nexus?  I mean, let's say that the community votes to approve the
>>>> release.  How do you propagate those voted-upon artifacts from staging
>>>> to the release repo?
>>>>
>>>
>>> The actual promoting is also just a couple clicks (or the plugin listed
>>> above)
>>> Upon promotion all the artifacts are moved into the release repository. (and
>>> corresponding metadata is merged i.e. maven-metadata.xml)
>>>
>>>
>>>
>>>>
>>>> Thanks for the pointers!
>>>>
>>>> - Les
>>>>
>>>
>>
>

Re: Preparing for our first release

Posted by Les Hazlewood <lh...@apache.org>.

The way we did this for JSecurity was to publish each release's
documentation to its own version specific directory.  Then I'd use a
symlink to point to the 'current' version and/or snapshot. I.E.:

http://shiro.apache.org/site/current/api

and in the site directory, you'd have the following directories:

0.9.2
1.0.0
1.0.3
1.0.4-SNAPSHOT

and each time we published something important, we changed 'current'
symlink to point to the latest release - it was really nice.  Can we
still do this?  Maybe not, but I'm just checking.  Will this work?

- Les

On Tue, Feb 9, 2010 at 12:36 PM, Kalle Korhonen
<ka...@gmail.com> wrote:
> Thanks to Brian for detailed instructions. I'm familiar with staged
> releases and Nexus so we should be able to get this done. I assume I'm
> going to cut the release when the time comes unless somebody else
> steps up :)
>
> Les, as Brian noted site's somewhat separate from the release but by
> default it's published at release time. Basically we have two options,
> either we publish just snapshots of the site (i.e. exactly one site
> url) or a site per release (i.e. site/1.0.0) and single url for
> snapshots, the latter can be achieved with profiles. Multiple archived
> and released sites could be useful (but also confusing) for users when
> we have multiple releases available, but just for simplicity's sake
> I'd go with a single site url at first. The javadocs are in any case
> deployed per released version.
>
> Kalle
>
>
> On Tue, Feb 9, 2010 at 7:49 AM, Brian Demers <br...@gmail.com> wrote:
>> Hey Les,
>>
>> On Tue, Feb 9, 2010 at 10:32 AM, Les Hazlewood <lh...@apache.org>wrote:
>>
>>> Hi Brian,
>>>
>>> > To get everything setup for a staging repository
>>> > Create a sub task under:
>>> https://issues.apache.org/jira/browse/INFRA-1896
>>>
>>> Done:
>>>
>>> https://issues.apache.org/jira/browse/INFRA-2488
>>>
>>> > After the deploy you need to close the staging repo, and promote it
>>>
>>> What do you mean by close the staging repo?  Just ensure that the team
>>> does not deploy to staging to prevent overwrites?
>>>
>>
>> A single maven deploy is a bunch of stateless deploys so there is no way to
>> know when maven is done deploying all the artifacts.  So after you do a
>> deploy you need to tell Nexus you are finished.  This puts the repository in
>> a read-only mode
>>
>> You could do this all from a maven plugin (but personally I like the UI for
>> this):
>> http://plugins.sonatype.org/nexus-maven-plugin/usage-staging.html
>>
>>
>>>
>>> Also, once the artifacts are in staging, how is promotion done in
>>> Nexus?  I mean, let's say that the community votes to approve the
>>> release.  How do you propagate those voted-upon artifacts from staging
>>> to the release repo?
>>>
>>
>> The actual promoting is also just a couple clicks (or the plugin listed
>> above)
>> Upon promotion all the artifacts are moved into the release repository. (and
>> corresponding metadata is merged i.e. maven-metadata.xml)
>>
>>
>>
>>>
>>> Thanks for the pointers!
>>>
>>> - Les
>>>
>>
>

Re: Preparing for our first release

Posted by Kalle Korhonen <ka...@gmail.com>.

Thanks to Brian for detailed instructions. I'm familiar with staged
releases and Nexus so we should be able to get this done. I assume I'm
going to cut the release when the time comes unless somebody else
steps up :)

Les, as Brian noted site's somewhat separate from the release but by
default it's published at release time. Basically we have two options,
either we publish just snapshots of the site (i.e. exactly one site
url) or a site per release (i.e. site/1.0.0) and single url for
snapshots, the latter can be achieved with profiles. Multiple archived
and released sites could be useful (but also confusing) for users when
we have multiple releases available, but just for simplicity's sake
I'd go with a single site url at first. The javadocs are in any case
deployed per released version.

Kalle

On Tue, Feb 9, 2010 at 7:49 AM, Brian Demers <br...@gmail.com> wrote:
> Hey Les,
>
> On Tue, Feb 9, 2010 at 10:32 AM, Les Hazlewood <lh...@apache.org>wrote:
>
>> Hi Brian,
>>
>> > To get everything setup for a staging repository
>> > Create a sub task under:
>> https://issues.apache.org/jira/browse/INFRA-1896
>>
>> Done:
>>
>> https://issues.apache.org/jira/browse/INFRA-2488
>>
>> > After the deploy you need to close the staging repo, and promote it
>>
>> What do you mean by close the staging repo?  Just ensure that the team
>> does not deploy to staging to prevent overwrites?
>>
>
> A single maven deploy is a bunch of stateless deploys so there is no way to
> know when maven is done deploying all the artifacts.  So after you do a
> deploy you need to tell Nexus you are finished.  This puts the repository in
> a read-only mode
>
> You could do this all from a maven plugin (but personally I like the UI for
> this):
> http://plugins.sonatype.org/nexus-maven-plugin/usage-staging.html
>
>
>>
>> Also, once the artifacts are in staging, how is promotion done in
>> Nexus?  I mean, let's say that the community votes to approve the
>> release.  How do you propagate those voted-upon artifacts from staging
>> to the release repo?
>>
>
> The actual promoting is also just a couple clicks (or the plugin listed
> above)
> Upon promotion all the artifacts are moved into the release repository. (and
> corresponding metadata is merged i.e. maven-metadata.xml)
>
>
>
>>
>> Thanks for the pointers!
>>
>> - Les
>>
>

Re: Preparing for our first release

Posted by Brian Demers <br...@gmail.com>.

Hey Les,

On Tue, Feb 9, 2010 at 10:32 AM, Les Hazlewood <lh...@apache.org>wrote:

> Hi Brian,
>
> > To get everything setup for a staging repository
> > Create a sub task under:
> https://issues.apache.org/jira/browse/INFRA-1896
>
> Done:
>
> https://issues.apache.org/jira/browse/INFRA-2488
>
> > After the deploy you need to close the staging repo, and promote it
>
> What do you mean by close the staging repo?  Just ensure that the team
> does not deploy to staging to prevent overwrites?
>

A single maven deploy is a bunch of stateless deploys so there is no way to
know when maven is done deploying all the artifacts.  So after you do a
deploy you need to tell Nexus you are finished.  This puts the repository in
a read-only mode

You could do this all from a maven plugin (but personally I like the UI for
this):
http://plugins.sonatype.org/nexus-maven-plugin/usage-staging.html

>
> Also, once the artifacts are in staging, how is promotion done in
> Nexus?  I mean, let's say that the community votes to approve the
> release.  How do you propagate those voted-upon artifacts from staging
> to the release repo?
>

The actual promoting is also just a couple clicks (or the plugin listed
above)
Upon promotion all the artifacts are moved into the release repository. (and
corresponding metadata is merged i.e. maven-metadata.xml)

>
> Thanks for the pointers!
>
> - Les
>

Re: Preparing for our first release

Posted by Les Hazlewood <lh...@apache.org>.

Hi Brian,

> To get everything setup for a staging repository
> Create a sub task under: https://issues.apache.org/jira/browse/INFRA-1896

Done:

https://issues.apache.org/jira/browse/INFRA-2488

> After the deploy you need to close the staging repo, and promote it

What do you mean by close the staging repo?  Just ensure that the team
does not deploy to staging to prevent overwrites?

Also, once the artifacts are in staging, how is promotion done in
Nexus?  I mean, let's say that the community votes to approve the
release.  How do you propagate those voted-upon artifacts from staging
to the release repo?

Thanks for the pointers!

- Les

Re: Preparing for our first release

Posted by Brian Demers <br...@gmail.com>.

To get everything setup for a staging repository at
repository.apache.org(RAO)  i.e. permissions copied over from SVN, etc
Create a sub task under: https://issues.apache.org/jira/browse/INFRA-1896

The deploy URL will be:
https://repository.apache.org/service/local/staging/deploy/maven2/
After the deploy you need to close the staging repo, and promote it
(typically between the staging and promoting is where the voting happens,
not sure what is needed for the incubator though)

Apache handles the sites differently, i think you need to deploy to and it
gets moved over hourly or something like that.
<url>scp://people.apache.org/www/incubator.apache.org/shiro/</url>

Any problems on the nexus side let me know.



On Tue, Feb 9, 2010 at 9:32 AM, Les Hazlewood <lh...@apache.org> wrote:
>
> Hi Kalle,
>
> This is really good stuff - thanks for figuring this stuff out :)  I
> agree that we should go the staged release route for safety, given
> that we haven't had our first approved release yet.
>
> How do the staged releases work in relation to the site?  Or do they?
> My assumption is that for a staged release, the maven created
> artifacts go into a special repository in Nexus.  Then after the
> release is approved, someone clicks a button, which moves them to the
> public repo.
>
> Is this correct?  Is the site handled differently?
>
> - Les
>
> On Mon, Feb 8, 2010 at 5:41 PM, Kalle Korhonen
> <ka...@gmail.com> wrote:
> > I've been looking at deploying the Maven site as secondary form of
> > documentation (cwiki being primary). After reading through
> > http://incubator.apache.org/guides/sites.html, I'm still not hyper
> > convinced that the produced Maven site would need to be fully
> > committed to svn. I didn't see any project currently in Incubator
> > who'd be using Maven to the fullest and though Chemistry has deployed
> > a Maven as their primary sits, it's not in svn and they don't have
> > distributionmanagement set up at all and Shindig, that graduated last
> > year, is directly deploying via scp. So, unless I hear otherwise, I'm
> > going to add this to the master pom:
> >    <distributionManagement>
> >        <site>
> >            <id>incubator.website</id>
> >            <name>Apache Incubator Site</name>
> >            <url>scp://
people.apache.org/www/incubator.apache.org/shiro/site</url>
> >        </site>
> >    </distributionManagement>
> >
> > I'm not sure if there's any common ids that should be used. Shindig
> > uses "apache.website" - I didn't find any documentation on that, does
> > anyone know better? I already deployed the top pom non-recursively as
> > a test and verified that the permissions are set correctly (I'm the
> > owner but write allowed for incubator group).
> >
> > I've also taken a look at the rules regarding distributing releases
> > and it seems that the apache parent pom and the instructions strongly
> > suggest using staged releases as opposed to blind releases (which we
> > earlier talked about doing at first). It's a bit more work but gives
> > us a chance to evaluate the produced binaries before they go out
> > publicly so I guess it's better to do it right from the beginning.
> > I'll work on release preparation but I think we are still a week or
> > two away from being able to release.
> >
> > Kalle
> >
> >
> > On Mon, Feb 1, 2010 at 9:41 PM, Kalle Korhonen
> > <ka...@gmail.com> wrote:
> >> Ha! I knew that would get the ball rolling :) I'll take care of
> >> SHIRO-59. Agree with everything Les said - API changes would be
> >> important to get in at this stage. I expect working through the
> >> release preparation will still take a couple of weeks and we probably
> >> have a good chance of closing out all of the remaining ones currently
> >> scheduled in that timeframe - but there's no point holding up the
> >> release if not.
> >>
> >> Kalle
> >>
> >>
> >> On Mon, Feb 1, 2010 at 8:39 PM, Les Hazlewood <lh...@apache.org>
wrote:
> >>> I definitely agree - there are a few critical issues that I'd like to
> >>> see if we can resolve:
> >>>
> >>> -  The RememberMeManager acquires the HttpServletRequest/Response pair
> >>> from the ThreadLocal - I was thinking that might require an API change
> >>> to the RememberMeManager to accept it as a method argument or in the
> >>> Subject context map.
> >>> - 'Run As' is about 50% done.  It shouldn't take much longer to finish
> >>> - As Brian suggested, his patches would be a nice edition for the 1.0
release.
> >>>
> >>> I agree that most of the other issues won't be done for the 1.0
> >>> release, but that's ok - that's what 1.1 will be for or 1.2 or
> >>> whatever.  It's definitely a good idea to get 1.0 out now to service
> >>> the community's needs.
> >>>
> >>> We're definitely close!
> >>>
> >>> Cheers,
> >>>
> >>> Les
> >>>
> >>> On Mon, Feb 1, 2010 at 10:54 PM, Kalle Korhonen
> >>> <ka...@gmail.com> wrote:
> >>>> I think it's a high time to do our first release. There's quite a few
> >>>> smallish organizational and/or configuration items we need to do
> >>>> before a release, most of them nicely tracked at
> >>>> http://incubator.apache.org/clutch.html. Color-wise, we are not doing
> >>>> that bad but we could do better. Don't care about the all green much
> >>>> but the page is tracking the right items, so I just picked up the
> >>>> hammer and I'll start swinging. I'll be updating the progress here
and
> >>>> in case I run into issues. I'll first create the distribution area
and
> >>>> publish our site docs there. If there are any open issues any of you
> >>>> would like to get closed before 1.0.0 better start working on them
> >>>> now.. I don't think we are going to wait for all of the issues
> >>>> currently scheduled for 1.0
> >>>> (
https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=12310950&fixfor=12314078
)
> >>>> to be completed unless they are critical/blocker. We'll just schedule
> >>>> them for a later point release if not done until we are otherwise
> >>>> ready for 1.0.0. Agree?
> >>>>
> >>>> Kalle
> >>>>
> >>>>
> >>>> On Fri, Dec 18, 2009 at 1:19 PM, Les Hazlewood <lh...@apache.org>
wrote:
> >>>>> Thanks!
> >>>>>
> >>>>> On Fri, Dec 18, 2009 at 4:17 PM, Alan D. Cabrera <
list@toolazydogs.com> wrote:
> >>>>>> Done.
> >>>>>>
> >>>>>>
> >>>>>> Regards,
> >>>>>> Alan
> >>>>>>
> >>>>>> On Dec 18, 2009, at 1:06 PM, Les Hazlewood wrote:
> >>>>>>
> >>>>>>> In light of this, could you please resolve the following issue?
> >>>>>>>
> >>>>>>> https://issues.apache.org/jira/browse/SHIRO-41
> >>>>>>>
> >>>>>>> Thanks,
> >>>>>>>
> >>>>>>> Les
> >>>>>>>
> >>>>>>> On Wed, Dec 16, 2009 at 11:16 AM, Alan D. Cabrera <
list@toolazydogs.com>
> >>>>>>> wrote:
> >>>>>>>>
> >>>>>>>> For artwork it can get complicated but only if you received
stipulations
> >>>>>>>> on
> >>>>>>>> its usage; it doesn't seem that there is any.  I think we're good
here.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Regards,
> >>>>>>>> Alan
> >>>>>>>>
> >>>>>>>> On Dec 16, 2009, at 7:33 AM, Les Hazlewood wrote:
> >>>>>>>>
> >>>>>>>>> There is one minor thing I forgot to mention:  Jeremy's friend
created
> >>>>>>>>> the old JSecurity shield/lock logo for us.  He did the logo for
us in
> >>>>>>>>> return for free website hosting on one of our servers.  This is
> >>>>>>>>> payment for services rendered (he payed us by doing the logo
work, the
> >>>>>>>>> services rendered were the website hosting), so I don't think
that we
> >>>>>>>>> need a CLA/sign-off from him.
> >>>>>>>>>
> >>>>>>>>> As I understand it, the shield/lock logo is our intellectual
property
> >>>>>>>>> due to this agreement and we don't need to involve him.  IANAL,
but I
> >>>>>>>>> think we're ok.
> >>>>>>>>>
> >>>>>>>>> - Les
> >>>>>>>>>
> >>>>>>>>> On Wed, Dec 16, 2009 at 10:26 AM, Les Hazlewood <
lhazlewood@apache.org>
> >>>>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>> Yep, it did.  Just for clarity's sake: every contributor on the
old
> >>>>>>>>>> JSecurity project came over as a committer to Apache and each
also
> >>>>>>>>>> sent the re-licensing agreement/affirmation at that time.
> >>>>>>>>>>
> >>>>>>>>>> Cheers,
> >>>>>>>>>>
> >>>>>>>>>> Les
> >>>>>>>>>>
> >>>>>>>>>> On Wed, Dec 16, 2009 at 10:22 AM, Alan D. Cabrera
> >>>>>>>>>> <li...@toolazydogs.com>
> >>>>>>>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>> So, back in July Craig sent out a set of emails from
committers in the
> >>>>>>>>>>> project stating that re-licensing for ASF.  What I am not sure
of is
> >>>>>>>>>>> that
> >>>>>>>>>>> this covers *all* the original authors from the JSecurity
project
> >>>>>>>>>>> before
> >>>>>>>>>>> it
> >>>>>>>>>>> arrived at the Incubator.
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> Regards,
> >>>>>>>>>>> Alan
> >>>>>>>>>>>
> >>>>>>>>>>> On Dec 8, 2009, at 6:42 AM, Les Hazlewood wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> Craig, can you please just confirm this so we have a clear
record of
> >>>>>>>>>>>> it?
> >>>>>>>>>>>>
> >>>>>>>>>>>> Thanks,
> >>>>>>>>>>>>
> >>>>>>>>>>>> Les
> >>>>>>>>>>>>
> >>>>>>>>>>>> On Tue, Dec 8, 2009 at 9:26 AM, Alan D. Cabrera
> >>>>>>>>>>>> <li...@toolazydogs.com>
> >>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> If Craig has confirmed that all the original authors from
JSecurity
> >>>>>>>>>>>>> have
> >>>>>>>>>>>>> filed a license agreement then I think we're good.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Regards,
> >>>>>>>>>>>>> Alan
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> On Dec 7, 2009, at 4:58 PM, Les Hazlewood wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> Yep, we're covered.  All people who contributed previously
to
> >>>>>>>>>>>>>> JSecurity became committers to Shiro.  Before joining the
> >>>>>>>>>>>>>> incubator,
> >>>>>>>>>>>>>> we all formally (each) agreed to the transfer.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> HTH,
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Les
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> On Mon, Dec 7, 2009 at 5:27 PM, Alan D. Cabrera
> >>>>>>>>>>>>>> <li...@toolazydogs.com>
> >>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> I recall that agreements were forwarded by current project
> >>>>>>>>>>>>>>> members.
> >>>>>>>>>>>>>>>  I'm
> >>>>>>>>>>>>>>> not
> >>>>>>>>>>>>>>> certain that we covered all the people who contributed to
the
> >>>>>>>>>>>>>>> original
> >>>>>>>>>>>>>>> project.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Regards,
> >>>>>>>>>>>>>>> Alan
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> On Dec 7, 2009, at 11:40 AM, Les Hazlewood wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> To the best of my knowledge this is all finished - Craig
helped
> >>>>>>>>>>>>>>>> out
> >>>>>>>>>>>>>>>> with it.  I forwarded all the formal statements from all
previous
> >>>>>>>>>>>>>>>> committers that they fully agree and support of
transferring all
> >>>>>>>>>>>>>>>> of
> >>>>>>>>>>>>>>>> their work to the ASF 2.0 license.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Craig, could you please clarify if there's anything else
that
> >>>>>>>>>>>>>>>> needs
> >>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>> be
> >>>>>>>>>>>>>>>> done?
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Thanks!
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Les
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> On Mon, Dec 7, 2009 at 1:31 PM, Alan D. Cabrera
> >>>>>>>>>>>>>>>> <li...@toolazydogs.com>
> >>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> On Dec 7, 2009, at 7:44 AM, Les Hazlewood 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.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Sounds great!
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> The only thing that's hazy in my mind is the LGPL
vetting.  I
> >>>>>>>>>>>>>>>>> recall
> >>>>>>>>>>>>>>>>> an
> >>>>>>>>>>>>>>>>> effort to obtain permission to relicense the code from
the
> >>>>>>>>>>>>>>>>> original
> >>>>>>>>>>>>>>>>> authors
> >>>>>>>>>>>>>>>>> but am not sure if it was completed and all the
requisite
> >>>>>>>>>>>>>>>>> permissions
> >>>>>>>>>>>>>>>>> were
> >>>>>>>>>>>>>>>>> properly filed.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Regards,
> >>>>>>>>>>>>>>>>> Alan
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> >

Re: Preparing for our first release

Posted by Les Hazlewood <lh...@apache.org>.

Hi Kalle,

This is really good stuff - thanks for figuring this stuff out :)  I
agree that we should go the staged release route for safety, given
that we haven't had our first approved release yet.

How do the staged releases work in relation to the site?  Or do they?
My assumption is that for a staged release, the maven created
artifacts go into a special repository in Nexus.  Then after the
release is approved, someone clicks a button, which moves them to the
public repo.

Is this correct?  Is the site handled differently?

- Les

On Mon, Feb 8, 2010 at 5:41 PM, Kalle Korhonen
<ka...@gmail.com> wrote:
> I've been looking at deploying the Maven site as secondary form of
> documentation (cwiki being primary). After reading through
> http://incubator.apache.org/guides/sites.html, I'm still not hyper
> convinced that the produced Maven site would need to be fully
> committed to svn. I didn't see any project currently in Incubator
> who'd be using Maven to the fullest and though Chemistry has deployed
> a Maven as their primary sits, it's not in svn and they don't have
> distributionmanagement set up at all and Shindig, that graduated last
> year, is directly deploying via scp. So, unless I hear otherwise, I'm
> going to add this to the master pom:
>    <distributionManagement>
>        <site>
>            <id>incubator.website</id>
>            <name>Apache Incubator Site</name>
>            <url>scp://people.apache.org/www/incubator.apache.org/shiro/site</url>
>        </site>
>    </distributionManagement>
>
> I'm not sure if there's any common ids that should be used. Shindig
> uses "apache.website" - I didn't find any documentation on that, does
> anyone know better? I already deployed the top pom non-recursively as
> a test and verified that the permissions are set correctly (I'm the
> owner but write allowed for incubator group).
>
> I've also taken a look at the rules regarding distributing releases
> and it seems that the apache parent pom and the instructions strongly
> suggest using staged releases as opposed to blind releases (which we
> earlier talked about doing at first). It's a bit more work but gives
> us a chance to evaluate the produced binaries before they go out
> publicly so I guess it's better to do it right from the beginning.
> I'll work on release preparation but I think we are still a week or
> two away from being able to release.
>
> Kalle
>
>
> On Mon, Feb 1, 2010 at 9:41 PM, Kalle Korhonen
> <ka...@gmail.com> wrote:
>> Ha! I knew that would get the ball rolling :) I'll take care of
>> SHIRO-59. Agree with everything Les said - API changes would be
>> important to get in at this stage. I expect working through the
>> release preparation will still take a couple of weeks and we probably
>> have a good chance of closing out all of the remaining ones currently
>> scheduled in that timeframe - but there's no point holding up the
>> release if not.
>>
>> Kalle
>>
>>
>> On Mon, Feb 1, 2010 at 8:39 PM, Les Hazlewood <lh...@apache.org> wrote:
>>> I definitely agree - there are a few critical issues that I'd like to
>>> see if we can resolve:
>>>
>>> -  The RememberMeManager acquires the HttpServletRequest/Response pair
>>> from the ThreadLocal - I was thinking that might require an API change
>>> to the RememberMeManager to accept it as a method argument or in the
>>> Subject context map.
>>> - 'Run As' is about 50% done.  It shouldn't take much longer to finish
>>> - As Brian suggested, his patches would be a nice edition for the 1.0 release.
>>>
>>> I agree that most of the other issues won't be done for the 1.0
>>> release, but that's ok - that's what 1.1 will be for or 1.2 or
>>> whatever.  It's definitely a good idea to get 1.0 out now to service
>>> the community's needs.
>>>
>>> We're definitely close!
>>>
>>> Cheers,
>>>
>>> Les
>>>
>>> On Mon, Feb 1, 2010 at 10:54 PM, Kalle Korhonen
>>> <ka...@gmail.com> wrote:
>>>> I think it's a high time to do our first release. There's quite a few
>>>> smallish organizational and/or configuration items we need to do
>>>> before a release, most of them nicely tracked at
>>>> http://incubator.apache.org/clutch.html. Color-wise, we are not doing
>>>> that bad but we could do better. Don't care about the all green much
>>>> but the page is tracking the right items, so I just picked up the
>>>> hammer and I'll start swinging. I'll be updating the progress here and
>>>> in case I run into issues. I'll first create the distribution area and
>>>> publish our site docs there. If there are any open issues any of you
>>>> would like to get closed before 1.0.0 better start working on them
>>>> now.. I don't think we are going to wait for all of the issues
>>>> currently scheduled for 1.0
>>>> (https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=12310950&fixfor=12314078)
>>>> to be completed unless they are critical/blocker. We'll just schedule
>>>> them for a later point release if not done until we are otherwise
>>>> ready for 1.0.0. Agree?
>>>>
>>>> Kalle
>>>>
>>>>
>>>> On Fri, Dec 18, 2009 at 1:19 PM, Les Hazlewood <lh...@apache.org> wrote:
>>>>> Thanks!
>>>>>
>>>>> On Fri, Dec 18, 2009 at 4:17 PM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>>>>>> Done.
>>>>>>
>>>>>>
>>>>>> Regards,
>>>>>> Alan
>>>>>>
>>>>>> On Dec 18, 2009, at 1:06 PM, Les Hazlewood wrote:
>>>>>>
>>>>>>> In light of this, could you please resolve the following issue?
>>>>>>>
>>>>>>> https://issues.apache.org/jira/browse/SHIRO-41
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Les
>>>>>>>
>>>>>>> On Wed, Dec 16, 2009 at 11:16 AM, Alan D. Cabrera <li...@toolazydogs.com>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> For artwork it can get complicated but only if you received stipulations
>>>>>>>> on
>>>>>>>> its usage; it doesn't seem that there is any.  I think we're good here.
>>>>>>>>
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Alan
>>>>>>>>
>>>>>>>> On Dec 16, 2009, at 7:33 AM, Les Hazlewood wrote:
>>>>>>>>
>>>>>>>>> There is one minor thing I forgot to mention:  Jeremy's friend created
>>>>>>>>> the old JSecurity shield/lock logo for us.  He did the logo for us in
>>>>>>>>> return for free website hosting on one of our servers.  This is
>>>>>>>>> payment for services rendered (he payed us by doing the logo work, the
>>>>>>>>> services rendered were the website hosting), so I don't think that we
>>>>>>>>> need a CLA/sign-off from him.
>>>>>>>>>
>>>>>>>>> As I understand it, the shield/lock logo is our intellectual property
>>>>>>>>> due to this agreement and we don't need to involve him.  IANAL, but I
>>>>>>>>> think we're ok.
>>>>>>>>>
>>>>>>>>> - Les
>>>>>>>>>
>>>>>>>>> On Wed, Dec 16, 2009 at 10:26 AM, Les Hazlewood <lh...@apache.org>
>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> Yep, it did.  Just for clarity's sake: every contributor on the old
>>>>>>>>>> JSecurity project came over as a committer to Apache and each also
>>>>>>>>>> sent the re-licensing agreement/affirmation at that time.
>>>>>>>>>>
>>>>>>>>>> Cheers,
>>>>>>>>>>
>>>>>>>>>> Les
>>>>>>>>>>
>>>>>>>>>> On Wed, Dec 16, 2009 at 10:22 AM, Alan D. Cabrera
>>>>>>>>>> <li...@toolazydogs.com>
>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> So, back in July Craig sent out a set of emails from committers in the
>>>>>>>>>>> project stating that re-licensing for ASF.  What I am not sure of is
>>>>>>>>>>> that
>>>>>>>>>>> this covers *all* the original authors from the JSecurity project
>>>>>>>>>>> before
>>>>>>>>>>> it
>>>>>>>>>>> arrived at the Incubator.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Regards,
>>>>>>>>>>> Alan
>>>>>>>>>>>
>>>>>>>>>>> On Dec 8, 2009, at 6:42 AM, Les Hazlewood wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Craig, can you please just confirm this so we have a clear record of
>>>>>>>>>>>> it?
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>
>>>>>>>>>>>> Les
>>>>>>>>>>>>
>>>>>>>>>>>> On Tue, Dec 8, 2009 at 9:26 AM, Alan D. Cabrera
>>>>>>>>>>>> <li...@toolazydogs.com>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> If Craig has confirmed that all the original authors from JSecurity
>>>>>>>>>>>>> have
>>>>>>>>>>>>> filed a license agreement then I think we're good.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>> Alan
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Dec 7, 2009, at 4:58 PM, Les Hazlewood wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Yep, we're covered.  All people who contributed previously to
>>>>>>>>>>>>>> JSecurity became committers to Shiro.  Before joining the
>>>>>>>>>>>>>> incubator,
>>>>>>>>>>>>>> we all formally (each) agreed to the transfer.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> HTH,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Les
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Mon, Dec 7, 2009 at 5:27 PM, Alan D. Cabrera
>>>>>>>>>>>>>> <li...@toolazydogs.com>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I recall that agreements were forwarded by current project
>>>>>>>>>>>>>>> members.
>>>>>>>>>>>>>>>  I'm
>>>>>>>>>>>>>>> not
>>>>>>>>>>>>>>> certain that we covered all the people who contributed to the
>>>>>>>>>>>>>>> original
>>>>>>>>>>>>>>> project.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>> Alan
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Dec 7, 2009, at 11:40 AM, Les Hazlewood wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> To the best of my knowledge this is all finished - Craig helped
>>>>>>>>>>>>>>>> out
>>>>>>>>>>>>>>>> with it.  I forwarded all the formal statements from all previous
>>>>>>>>>>>>>>>> committers that they fully agree and support of transferring all
>>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>> their work to the ASF 2.0 license.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Craig, could you please clarify if there's anything else that
>>>>>>>>>>>>>>>> needs
>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>> done?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thanks!
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Les
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Mon, Dec 7, 2009 at 1:31 PM, Alan D. Cabrera
>>>>>>>>>>>>>>>> <li...@toolazydogs.com>
>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Dec 7, 2009, at 7:44 AM, Les Hazlewood 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.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Sounds great!
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The only thing that's hazy in my mind is the LGPL vetting.  I
>>>>>>>>>>>>>>>>> recall
>>>>>>>>>>>>>>>>> an
>>>>>>>>>>>>>>>>> effort to obtain permission to relicense the code from the
>>>>>>>>>>>>>>>>> original
>>>>>>>>>>>>>>>>> authors
>>>>>>>>>>>>>>>>> but am not sure if it was completed and all the requisite
>>>>>>>>>>>>>>>>> permissions
>>>>>>>>>>>>>>>>> were
>>>>>>>>>>>>>>>>> properly filed.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>>>> Alan
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

Re: Preparing for our first release

Posted by Kalle Korhonen <ka...@gmail.com>.

I've been looking at deploying the Maven site as secondary form of
documentation (cwiki being primary). After reading through
http://incubator.apache.org/guides/sites.html, I'm still not hyper
convinced that the produced Maven site would need to be fully
committed to svn. I didn't see any project currently in Incubator
who'd be using Maven to the fullest and though Chemistry has deployed
a Maven as their primary sits, it's not in svn and they don't have
distributionmanagement set up at all and Shindig, that graduated last
year, is directly deploying via scp. So, unless I hear otherwise, I'm
going to add this to the master pom:
    <distributionManagement>
        <site>
            <id>incubator.website</id>
            <name>Apache Incubator Site</name>
            <url>scp://people.apache.org/www/incubator.apache.org/shiro/site</url>
        </site>
    </distributionManagement>

I'm not sure if there's any common ids that should be used. Shindig
uses "apache.website" - I didn't find any documentation on that, does
anyone know better? I already deployed the top pom non-recursively as
a test and verified that the permissions are set correctly (I'm the
owner but write allowed for incubator group).

I've also taken a look at the rules regarding distributing releases
and it seems that the apache parent pom and the instructions strongly
suggest using staged releases as opposed to blind releases (which we
earlier talked about doing at first). It's a bit more work but gives
us a chance to evaluate the produced binaries before they go out
publicly so I guess it's better to do it right from the beginning.
I'll work on release preparation but I think we are still a week or
two away from being able to release.

Kalle


On Mon, Feb 1, 2010 at 9:41 PM, Kalle Korhonen
<ka...@gmail.com> wrote:
> Ha! I knew that would get the ball rolling :) I'll take care of
> SHIRO-59. Agree with everything Les said - API changes would be
> important to get in at this stage. I expect working through the
> release preparation will still take a couple of weeks and we probably
> have a good chance of closing out all of the remaining ones currently
> scheduled in that timeframe - but there's no point holding up the
> release if not.
>
> Kalle
>
>
> On Mon, Feb 1, 2010 at 8:39 PM, Les Hazlewood <lh...@apache.org> wrote:
>> I definitely agree - there are a few critical issues that I'd like to
>> see if we can resolve:
>>
>> -  The RememberMeManager acquires the HttpServletRequest/Response pair
>> from the ThreadLocal - I was thinking that might require an API change
>> to the RememberMeManager to accept it as a method argument or in the
>> Subject context map.
>> - 'Run As' is about 50% done.  It shouldn't take much longer to finish
>> - As Brian suggested, his patches would be a nice edition for the 1.0 release.
>>
>> I agree that most of the other issues won't be done for the 1.0
>> release, but that's ok - that's what 1.1 will be for or 1.2 or
>> whatever.  It's definitely a good idea to get 1.0 out now to service
>> the community's needs.
>>
>> We're definitely close!
>>
>> Cheers,
>>
>> Les
>>
>> On Mon, Feb 1, 2010 at 10:54 PM, Kalle Korhonen
>> <ka...@gmail.com> wrote:
>>> I think it's a high time to do our first release. There's quite a few
>>> smallish organizational and/or configuration items we need to do
>>> before a release, most of them nicely tracked at
>>> http://incubator.apache.org/clutch.html. Color-wise, we are not doing
>>> that bad but we could do better. Don't care about the all green much
>>> but the page is tracking the right items, so I just picked up the
>>> hammer and I'll start swinging. I'll be updating the progress here and
>>> in case I run into issues. I'll first create the distribution area and
>>> publish our site docs there. If there are any open issues any of you
>>> would like to get closed before 1.0.0 better start working on them
>>> now.. I don't think we are going to wait for all of the issues
>>> currently scheduled for 1.0
>>> (https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=12310950&fixfor=12314078)
>>> to be completed unless they are critical/blocker. We'll just schedule
>>> them for a later point release if not done until we are otherwise
>>> ready for 1.0.0. Agree?
>>>
>>> Kalle
>>>
>>>
>>> On Fri, Dec 18, 2009 at 1:19 PM, Les Hazlewood <lh...@apache.org> wrote:
>>>> Thanks!
>>>>
>>>> On Fri, Dec 18, 2009 at 4:17 PM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>>>>> Done.
>>>>>
>>>>>
>>>>> Regards,
>>>>> Alan
>>>>>
>>>>> On Dec 18, 2009, at 1:06 PM, Les Hazlewood wrote:
>>>>>
>>>>>> In light of this, could you please resolve the following issue?
>>>>>>
>>>>>> https://issues.apache.org/jira/browse/SHIRO-41
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Les
>>>>>>
>>>>>> On Wed, Dec 16, 2009 at 11:16 AM, Alan D. Cabrera <li...@toolazydogs.com>
>>>>>> wrote:
>>>>>>>
>>>>>>> For artwork it can get complicated but only if you received stipulations
>>>>>>> on
>>>>>>> its usage; it doesn't seem that there is any.  I think we're good here.
>>>>>>>
>>>>>>>
>>>>>>> Regards,
>>>>>>> Alan
>>>>>>>
>>>>>>> On Dec 16, 2009, at 7:33 AM, Les Hazlewood wrote:
>>>>>>>
>>>>>>>> There is one minor thing I forgot to mention:  Jeremy's friend created
>>>>>>>> the old JSecurity shield/lock logo for us.  He did the logo for us in
>>>>>>>> return for free website hosting on one of our servers.  This is
>>>>>>>> payment for services rendered (he payed us by doing the logo work, the
>>>>>>>> services rendered were the website hosting), so I don't think that we
>>>>>>>> need a CLA/sign-off from him.
>>>>>>>>
>>>>>>>> As I understand it, the shield/lock logo is our intellectual property
>>>>>>>> due to this agreement and we don't need to involve him.  IANAL, but I
>>>>>>>> think we're ok.
>>>>>>>>
>>>>>>>> - Les
>>>>>>>>
>>>>>>>> On Wed, Dec 16, 2009 at 10:26 AM, Les Hazlewood <lh...@apache.org>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Yep, it did.  Just for clarity's sake: every contributor on the old
>>>>>>>>> JSecurity project came over as a committer to Apache and each also
>>>>>>>>> sent the re-licensing agreement/affirmation at that time.
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>>
>>>>>>>>> Les
>>>>>>>>>
>>>>>>>>> On Wed, Dec 16, 2009 at 10:22 AM, Alan D. Cabrera
>>>>>>>>> <li...@toolazydogs.com>
>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> So, back in July Craig sent out a set of emails from committers in the
>>>>>>>>>> project stating that re-licensing for ASF.  What I am not sure of is
>>>>>>>>>> that
>>>>>>>>>> this covers *all* the original authors from the JSecurity project
>>>>>>>>>> before
>>>>>>>>>> it
>>>>>>>>>> arrived at the Incubator.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>> Alan
>>>>>>>>>>
>>>>>>>>>> On Dec 8, 2009, at 6:42 AM, Les Hazlewood wrote:
>>>>>>>>>>
>>>>>>>>>>> Craig, can you please just confirm this so we have a clear record of
>>>>>>>>>>> it?
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>>
>>>>>>>>>>> Les
>>>>>>>>>>>
>>>>>>>>>>> On Tue, Dec 8, 2009 at 9:26 AM, Alan D. Cabrera
>>>>>>>>>>> <li...@toolazydogs.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> If Craig has confirmed that all the original authors from JSecurity
>>>>>>>>>>>> have
>>>>>>>>>>>> filed a license agreement then I think we're good.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Regards,
>>>>>>>>>>>> Alan
>>>>>>>>>>>>
>>>>>>>>>>>> On Dec 7, 2009, at 4:58 PM, Les Hazlewood wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Yep, we're covered.  All people who contributed previously to
>>>>>>>>>>>>> JSecurity became committers to Shiro.  Before joining the
>>>>>>>>>>>>> incubator,
>>>>>>>>>>>>> we all formally (each) agreed to the transfer.
>>>>>>>>>>>>>
>>>>>>>>>>>>> HTH,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Les
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Mon, Dec 7, 2009 at 5:27 PM, Alan D. Cabrera
>>>>>>>>>>>>> <li...@toolazydogs.com>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I recall that agreements were forwarded by current project
>>>>>>>>>>>>>> members.
>>>>>>>>>>>>>>  I'm
>>>>>>>>>>>>>> not
>>>>>>>>>>>>>> certain that we covered all the people who contributed to the
>>>>>>>>>>>>>> original
>>>>>>>>>>>>>> project.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>> Alan
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Dec 7, 2009, at 11:40 AM, Les Hazlewood wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> To the best of my knowledge this is all finished - Craig helped
>>>>>>>>>>>>>>> out
>>>>>>>>>>>>>>> with it.  I forwarded all the formal statements from all previous
>>>>>>>>>>>>>>> committers that they fully agree and support of transferring all
>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>> their work to the ASF 2.0 license.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Craig, could you please clarify if there's anything else that
>>>>>>>>>>>>>>> needs
>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>> done?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks!
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Les
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Mon, Dec 7, 2009 at 1:31 PM, Alan D. Cabrera
>>>>>>>>>>>>>>> <li...@toolazydogs.com>
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Dec 7, 2009, at 7:44 AM, Les Hazlewood 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.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Sounds great!
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The only thing that's hazy in my mind is the LGPL vetting.  I
>>>>>>>>>>>>>>>> recall
>>>>>>>>>>>>>>>> an
>>>>>>>>>>>>>>>> effort to obtain permission to relicense the code from the
>>>>>>>>>>>>>>>> original
>>>>>>>>>>>>>>>> authors
>>>>>>>>>>>>>>>> but am not sure if it was completed and all the requisite
>>>>>>>>>>>>>>>> permissions
>>>>>>>>>>>>>>>> were
>>>>>>>>>>>>>>>> properly filed.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>>> Alan
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>

Re: Preparing for our first release

Posted by Kalle Korhonen <ka...@gmail.com>.

Ha! I knew that would get the ball rolling :) I'll take care of
SHIRO-59. Agree with everything Les said - API changes would be
important to get in at this stage. I expect working through the
release preparation will still take a couple of weeks and we probably
have a good chance of closing out all of the remaining ones currently
scheduled in that timeframe - but there's no point holding up the
release if not.

Kalle


On Mon, Feb 1, 2010 at 8:39 PM, Les Hazlewood <lh...@apache.org> wrote:
> I definitely agree - there are a few critical issues that I'd like to
> see if we can resolve:
>
> -  The RememberMeManager acquires the HttpServletRequest/Response pair
> from the ThreadLocal - I was thinking that might require an API change
> to the RememberMeManager to accept it as a method argument or in the
> Subject context map.
> - 'Run As' is about 50% done.  It shouldn't take much longer to finish
> - As Brian suggested, his patches would be a nice edition for the 1.0 release.
>
> I agree that most of the other issues won't be done for the 1.0
> release, but that's ok - that's what 1.1 will be for or 1.2 or
> whatever.  It's definitely a good idea to get 1.0 out now to service
> the community's needs.
>
> We're definitely close!
>
> Cheers,
>
> Les
>
> On Mon, Feb 1, 2010 at 10:54 PM, Kalle Korhonen
> <ka...@gmail.com> wrote:
>> I think it's a high time to do our first release. There's quite a few
>> smallish organizational and/or configuration items we need to do
>> before a release, most of them nicely tracked at
>> http://incubator.apache.org/clutch.html. Color-wise, we are not doing
>> that bad but we could do better. Don't care about the all green much
>> but the page is tracking the right items, so I just picked up the
>> hammer and I'll start swinging. I'll be updating the progress here and
>> in case I run into issues. I'll first create the distribution area and
>> publish our site docs there. If there are any open issues any of you
>> would like to get closed before 1.0.0 better start working on them
>> now.. I don't think we are going to wait for all of the issues
>> currently scheduled for 1.0
>> (https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=12310950&fixfor=12314078)
>> to be completed unless they are critical/blocker. We'll just schedule
>> them for a later point release if not done until we are otherwise
>> ready for 1.0.0. Agree?
>>
>> Kalle
>>
>>
>> On Fri, Dec 18, 2009 at 1:19 PM, Les Hazlewood <lh...@apache.org> wrote:
>>> Thanks!
>>>
>>> On Fri, Dec 18, 2009 at 4:17 PM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>>>> Done.
>>>>
>>>>
>>>> Regards,
>>>> Alan
>>>>
>>>> On Dec 18, 2009, at 1:06 PM, Les Hazlewood wrote:
>>>>
>>>>> In light of this, could you please resolve the following issue?
>>>>>
>>>>> https://issues.apache.org/jira/browse/SHIRO-41
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Les
>>>>>
>>>>> On Wed, Dec 16, 2009 at 11:16 AM, Alan D. Cabrera <li...@toolazydogs.com>
>>>>> wrote:
>>>>>>
>>>>>> For artwork it can get complicated but only if you received stipulations
>>>>>> on
>>>>>> its usage; it doesn't seem that there is any.  I think we're good here.
>>>>>>
>>>>>>
>>>>>> Regards,
>>>>>> Alan
>>>>>>
>>>>>> On Dec 16, 2009, at 7:33 AM, Les Hazlewood wrote:
>>>>>>
>>>>>>> There is one minor thing I forgot to mention:  Jeremy's friend created
>>>>>>> the old JSecurity shield/lock logo for us.  He did the logo for us in
>>>>>>> return for free website hosting on one of our servers.  This is
>>>>>>> payment for services rendered (he payed us by doing the logo work, the
>>>>>>> services rendered were the website hosting), so I don't think that we
>>>>>>> need a CLA/sign-off from him.
>>>>>>>
>>>>>>> As I understand it, the shield/lock logo is our intellectual property
>>>>>>> due to this agreement and we don't need to involve him.  IANAL, but I
>>>>>>> think we're ok.
>>>>>>>
>>>>>>> - Les
>>>>>>>
>>>>>>> On Wed, Dec 16, 2009 at 10:26 AM, Les Hazlewood <lh...@apache.org>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Yep, it did.  Just for clarity's sake: every contributor on the old
>>>>>>>> JSecurity project came over as a committer to Apache and each also
>>>>>>>> sent the re-licensing agreement/affirmation at that time.
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>>
>>>>>>>> Les
>>>>>>>>
>>>>>>>> On Wed, Dec 16, 2009 at 10:22 AM, Alan D. Cabrera
>>>>>>>> <li...@toolazydogs.com>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> So, back in July Craig sent out a set of emails from committers in the
>>>>>>>>> project stating that re-licensing for ASF.  What I am not sure of is
>>>>>>>>> that
>>>>>>>>> this covers *all* the original authors from the JSecurity project
>>>>>>>>> before
>>>>>>>>> it
>>>>>>>>> arrived at the Incubator.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Alan
>>>>>>>>>
>>>>>>>>> On Dec 8, 2009, at 6:42 AM, Les Hazlewood wrote:
>>>>>>>>>
>>>>>>>>>> Craig, can you please just confirm this so we have a clear record of
>>>>>>>>>> it?
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>>
>>>>>>>>>> Les
>>>>>>>>>>
>>>>>>>>>> On Tue, Dec 8, 2009 at 9:26 AM, Alan D. Cabrera
>>>>>>>>>> <li...@toolazydogs.com>
>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> If Craig has confirmed that all the original authors from JSecurity
>>>>>>>>>>> have
>>>>>>>>>>> filed a license agreement then I think we're good.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Regards,
>>>>>>>>>>> Alan
>>>>>>>>>>>
>>>>>>>>>>> On Dec 7, 2009, at 4:58 PM, Les Hazlewood wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Yep, we're covered.  All people who contributed previously to
>>>>>>>>>>>> JSecurity became committers to Shiro.  Before joining the
>>>>>>>>>>>> incubator,
>>>>>>>>>>>> we all formally (each) agreed to the transfer.
>>>>>>>>>>>>
>>>>>>>>>>>> HTH,
>>>>>>>>>>>>
>>>>>>>>>>>> Les
>>>>>>>>>>>>
>>>>>>>>>>>> On Mon, Dec 7, 2009 at 5:27 PM, Alan D. Cabrera
>>>>>>>>>>>> <li...@toolazydogs.com>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> I recall that agreements were forwarded by current project
>>>>>>>>>>>>> members.
>>>>>>>>>>>>>  I'm
>>>>>>>>>>>>> not
>>>>>>>>>>>>> certain that we covered all the people who contributed to the
>>>>>>>>>>>>> original
>>>>>>>>>>>>> project.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>> Alan
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Dec 7, 2009, at 11:40 AM, Les Hazlewood wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> To the best of my knowledge this is all finished - Craig helped
>>>>>>>>>>>>>> out
>>>>>>>>>>>>>> with it.  I forwarded all the formal statements from all previous
>>>>>>>>>>>>>> committers that they fully agree and support of transferring all
>>>>>>>>>>>>>> of
>>>>>>>>>>>>>> their work to the ASF 2.0 license.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Craig, could you please clarify if there's anything else that
>>>>>>>>>>>>>> needs
>>>>>>>>>>>>>> to
>>>>>>>>>>>>>> be
>>>>>>>>>>>>>> done?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks!
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Les
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Mon, Dec 7, 2009 at 1:31 PM, Alan D. Cabrera
>>>>>>>>>>>>>> <li...@toolazydogs.com>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Dec 7, 2009, at 7:44 AM, Les Hazlewood 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.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Sounds great!
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The only thing that's hazy in my mind is the LGPL vetting.  I
>>>>>>>>>>>>>>> recall
>>>>>>>>>>>>>>> an
>>>>>>>>>>>>>>> effort to obtain permission to relicense the code from the
>>>>>>>>>>>>>>> original
>>>>>>>>>>>>>>> authors
>>>>>>>>>>>>>>> but am not sure if it was completed and all the requisite
>>>>>>>>>>>>>>> permissions
>>>>>>>>>>>>>>> were
>>>>>>>>>>>>>>> properly filed.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>> Alan
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>
>>
>

Re: Preparing for our first release

Posted by Les Hazlewood <lh...@apache.org>.

I definitely agree - there are a few critical issues that I'd like to
see if we can resolve:

-  The RememberMeManager acquires the HttpServletRequest/Response pair
from the ThreadLocal - I was thinking that might require an API change
to the RememberMeManager to accept it as a method argument or in the
Subject context map.
- 'Run As' is about 50% done.  It shouldn't take much longer to finish
- As Brian suggested, his patches would be a nice edition for the 1.0 release.

I agree that most of the other issues won't be done for the 1.0
release, but that's ok - that's what 1.1 will be for or 1.2 or
whatever.  It's definitely a good idea to get 1.0 out now to service
the community's needs.

We're definitely close!

Cheers,

Les

On Mon, Feb 1, 2010 at 10:54 PM, Kalle Korhonen
<ka...@gmail.com> wrote:
> I think it's a high time to do our first release. There's quite a few
> smallish organizational and/or configuration items we need to do
> before a release, most of them nicely tracked at
> http://incubator.apache.org/clutch.html. Color-wise, we are not doing
> that bad but we could do better. Don't care about the all green much
> but the page is tracking the right items, so I just picked up the
> hammer and I'll start swinging. I'll be updating the progress here and
> in case I run into issues. I'll first create the distribution area and
> publish our site docs there. If there are any open issues any of you
> would like to get closed before 1.0.0 better start working on them
> now.. I don't think we are going to wait for all of the issues
> currently scheduled for 1.0
> (https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=12310950&fixfor=12314078)
> to be completed unless they are critical/blocker. We'll just schedule
> them for a later point release if not done until we are otherwise
> ready for 1.0.0. Agree?
>
> Kalle
>
>
> On Fri, Dec 18, 2009 at 1:19 PM, Les Hazlewood <lh...@apache.org> wrote:
>> Thanks!
>>
>> On Fri, Dec 18, 2009 at 4:17 PM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>>> Done.
>>>
>>>
>>> Regards,
>>> Alan
>>>
>>> On Dec 18, 2009, at 1:06 PM, Les Hazlewood wrote:
>>>
>>>> In light of this, could you please resolve the following issue?
>>>>
>>>> https://issues.apache.org/jira/browse/SHIRO-41
>>>>
>>>> Thanks,
>>>>
>>>> Les
>>>>
>>>> On Wed, Dec 16, 2009 at 11:16 AM, Alan D. Cabrera <li...@toolazydogs.com>
>>>> wrote:
>>>>>
>>>>> For artwork it can get complicated but only if you received stipulations
>>>>> on
>>>>> its usage; it doesn't seem that there is any.  I think we're good here.
>>>>>
>>>>>
>>>>> Regards,
>>>>> Alan
>>>>>
>>>>> On Dec 16, 2009, at 7:33 AM, Les Hazlewood wrote:
>>>>>
>>>>>> There is one minor thing I forgot to mention:  Jeremy's friend created
>>>>>> the old JSecurity shield/lock logo for us.  He did the logo for us in
>>>>>> return for free website hosting on one of our servers.  This is
>>>>>> payment for services rendered (he payed us by doing the logo work, the
>>>>>> services rendered were the website hosting), so I don't think that we
>>>>>> need a CLA/sign-off from him.
>>>>>>
>>>>>> As I understand it, the shield/lock logo is our intellectual property
>>>>>> due to this agreement and we don't need to involve him.  IANAL, but I
>>>>>> think we're ok.
>>>>>>
>>>>>> - Les
>>>>>>
>>>>>> On Wed, Dec 16, 2009 at 10:26 AM, Les Hazlewood <lh...@apache.org>
>>>>>> wrote:
>>>>>>>
>>>>>>> Yep, it did.  Just for clarity's sake: every contributor on the old
>>>>>>> JSecurity project came over as a committer to Apache and each also
>>>>>>> sent the re-licensing agreement/affirmation at that time.
>>>>>>>
>>>>>>> Cheers,
>>>>>>>
>>>>>>> Les
>>>>>>>
>>>>>>> On Wed, Dec 16, 2009 at 10:22 AM, Alan D. Cabrera
>>>>>>> <li...@toolazydogs.com>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> So, back in July Craig sent out a set of emails from committers in the
>>>>>>>> project stating that re-licensing for ASF.  What I am not sure of is
>>>>>>>> that
>>>>>>>> this covers *all* the original authors from the JSecurity project
>>>>>>>> before
>>>>>>>> it
>>>>>>>> arrived at the Incubator.
>>>>>>>>
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Alan
>>>>>>>>
>>>>>>>> On Dec 8, 2009, at 6:42 AM, Les Hazlewood wrote:
>>>>>>>>
>>>>>>>>> Craig, can you please just confirm this so we have a clear record of
>>>>>>>>> it?
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>>
>>>>>>>>> Les
>>>>>>>>>
>>>>>>>>> On Tue, Dec 8, 2009 at 9:26 AM, Alan D. Cabrera
>>>>>>>>> <li...@toolazydogs.com>
>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> If Craig has confirmed that all the original authors from JSecurity
>>>>>>>>>> have
>>>>>>>>>> filed a license agreement then I think we're good.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>> Alan
>>>>>>>>>>
>>>>>>>>>> On Dec 7, 2009, at 4:58 PM, Les Hazlewood wrote:
>>>>>>>>>>
>>>>>>>>>>> Yep, we're covered.  All people who contributed previously to
>>>>>>>>>>> JSecurity became committers to Shiro.  Before joining the
>>>>>>>>>>> incubator,
>>>>>>>>>>> we all formally (each) agreed to the transfer.
>>>>>>>>>>>
>>>>>>>>>>> HTH,
>>>>>>>>>>>
>>>>>>>>>>> Les
>>>>>>>>>>>
>>>>>>>>>>> On Mon, Dec 7, 2009 at 5:27 PM, Alan D. Cabrera
>>>>>>>>>>> <li...@toolazydogs.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> I recall that agreements were forwarded by current project
>>>>>>>>>>>> members.
>>>>>>>>>>>>  I'm
>>>>>>>>>>>> not
>>>>>>>>>>>> certain that we covered all the people who contributed to the
>>>>>>>>>>>> original
>>>>>>>>>>>> project.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Regards,
>>>>>>>>>>>> Alan
>>>>>>>>>>>>
>>>>>>>>>>>> On Dec 7, 2009, at 11:40 AM, Les Hazlewood wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> To the best of my knowledge this is all finished - Craig helped
>>>>>>>>>>>>> out
>>>>>>>>>>>>> with it.  I forwarded all the formal statements from all previous
>>>>>>>>>>>>> committers that they fully agree and support of transferring all
>>>>>>>>>>>>> of
>>>>>>>>>>>>> their work to the ASF 2.0 license.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Craig, could you please clarify if there's anything else that
>>>>>>>>>>>>> needs
>>>>>>>>>>>>> to
>>>>>>>>>>>>> be
>>>>>>>>>>>>> done?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks!
>>>>>>>>>>>>>
>>>>>>>>>>>>> Les
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Mon, Dec 7, 2009 at 1:31 PM, Alan D. Cabrera
>>>>>>>>>>>>> <li...@toolazydogs.com>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Dec 7, 2009, at 7:44 AM, Les Hazlewood 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.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Sounds great!
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The only thing that's hazy in my mind is the LGPL vetting.  I
>>>>>>>>>>>>>> recall
>>>>>>>>>>>>>> an
>>>>>>>>>>>>>> effort to obtain permission to relicense the code from the
>>>>>>>>>>>>>> original
>>>>>>>>>>>>>> authors
>>>>>>>>>>>>>> but am not sure if it was completed and all the requisite
>>>>>>>>>>>>>> permissions
>>>>>>>>>>>>>> were
>>>>>>>>>>>>>> properly filed.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>> Alan
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>
>>>
>>
>

Re: Preparing for our first release

Posted by Kalle Korhonen <ka...@gmail.com>.

I think it's a high time to do our first release. There's quite a few
smallish organizational and/or configuration items we need to do
before a release, most of them nicely tracked at
http://incubator.apache.org/clutch.html. Color-wise, we are not doing
that bad but we could do better. Don't care about the all green much
but the page is tracking the right items, so I just picked up the
hammer and I'll start swinging. I'll be updating the progress here and
in case I run into issues. I'll first create the distribution area and
publish our site docs there. If there are any open issues any of you
would like to get closed before 1.0.0 better start working on them
now.. I don't think we are going to wait for all of the issues
currently scheduled for 1.0
(https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=12310950&fixfor=12314078)
to be completed unless they are critical/blocker. We'll just schedule
them for a later point release if not done until we are otherwise
ready for 1.0.0. Agree?

Kalle


On Fri, Dec 18, 2009 at 1:19 PM, Les Hazlewood <lh...@apache.org> wrote:
> Thanks!
>
> On Fri, Dec 18, 2009 at 4:17 PM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>> Done.
>>
>>
>> Regards,
>> Alan
>>
>> On Dec 18, 2009, at 1:06 PM, Les Hazlewood wrote:
>>
>>> In light of this, could you please resolve the following issue?
>>>
>>> https://issues.apache.org/jira/browse/SHIRO-41
>>>
>>> Thanks,
>>>
>>> Les
>>>
>>> On Wed, Dec 16, 2009 at 11:16 AM, Alan D. Cabrera <li...@toolazydogs.com>
>>> wrote:
>>>>
>>>> For artwork it can get complicated but only if you received stipulations
>>>> on
>>>> its usage; it doesn't seem that there is any.  I think we're good here.
>>>>
>>>>
>>>> Regards,
>>>> Alan
>>>>
>>>> On Dec 16, 2009, at 7:33 AM, Les Hazlewood wrote:
>>>>
>>>>> There is one minor thing I forgot to mention:  Jeremy's friend created
>>>>> the old JSecurity shield/lock logo for us.  He did the logo for us in
>>>>> return for free website hosting on one of our servers.  This is
>>>>> payment for services rendered (he payed us by doing the logo work, the
>>>>> services rendered were the website hosting), so I don't think that we
>>>>> need a CLA/sign-off from him.
>>>>>
>>>>> As I understand it, the shield/lock logo is our intellectual property
>>>>> due to this agreement and we don't need to involve him.  IANAL, but I
>>>>> think we're ok.
>>>>>
>>>>> - Les
>>>>>
>>>>> On Wed, Dec 16, 2009 at 10:26 AM, Les Hazlewood <lh...@apache.org>
>>>>> wrote:
>>>>>>
>>>>>> Yep, it did.  Just for clarity's sake: every contributor on the old
>>>>>> JSecurity project came over as a committer to Apache and each also
>>>>>> sent the re-licensing agreement/affirmation at that time.
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Les
>>>>>>
>>>>>> On Wed, Dec 16, 2009 at 10:22 AM, Alan D. Cabrera
>>>>>> <li...@toolazydogs.com>
>>>>>> wrote:
>>>>>>>
>>>>>>> So, back in July Craig sent out a set of emails from committers in the
>>>>>>> project stating that re-licensing for ASF.  What I am not sure of is
>>>>>>> that
>>>>>>> this covers *all* the original authors from the JSecurity project
>>>>>>> before
>>>>>>> it
>>>>>>> arrived at the Incubator.
>>>>>>>
>>>>>>>
>>>>>>> Regards,
>>>>>>> Alan
>>>>>>>
>>>>>>> On Dec 8, 2009, at 6:42 AM, Les Hazlewood wrote:
>>>>>>>
>>>>>>>> Craig, can you please just confirm this so we have a clear record of
>>>>>>>> it?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> Les
>>>>>>>>
>>>>>>>> On Tue, Dec 8, 2009 at 9:26 AM, Alan D. Cabrera
>>>>>>>> <li...@toolazydogs.com>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> If Craig has confirmed that all the original authors from JSecurity
>>>>>>>>> have
>>>>>>>>> filed a license agreement then I think we're good.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Alan
>>>>>>>>>
>>>>>>>>> On Dec 7, 2009, at 4:58 PM, Les Hazlewood wrote:
>>>>>>>>>
>>>>>>>>>> Yep, we're covered.  All people who contributed previously to
>>>>>>>>>> JSecurity became committers to Shiro.  Before joining the
>>>>>>>>>> incubator,
>>>>>>>>>> we all formally (each) agreed to the transfer.
>>>>>>>>>>
>>>>>>>>>> HTH,
>>>>>>>>>>
>>>>>>>>>> Les
>>>>>>>>>>
>>>>>>>>>> On Mon, Dec 7, 2009 at 5:27 PM, Alan D. Cabrera
>>>>>>>>>> <li...@toolazydogs.com>
>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> I recall that agreements were forwarded by current project
>>>>>>>>>>> members.
>>>>>>>>>>>  I'm
>>>>>>>>>>> not
>>>>>>>>>>> certain that we covered all the people who contributed to the
>>>>>>>>>>> original
>>>>>>>>>>> project.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Regards,
>>>>>>>>>>> Alan
>>>>>>>>>>>
>>>>>>>>>>> On Dec 7, 2009, at 11:40 AM, Les Hazlewood wrote:
>>>>>>>>>>>
>>>>>>>>>>>> To the best of my knowledge this is all finished - Craig helped
>>>>>>>>>>>> out
>>>>>>>>>>>> with it.  I forwarded all the formal statements from all previous
>>>>>>>>>>>> committers that they fully agree and support of transferring all
>>>>>>>>>>>> of
>>>>>>>>>>>> their work to the ASF 2.0 license.
>>>>>>>>>>>>
>>>>>>>>>>>> Craig, could you please clarify if there's anything else that
>>>>>>>>>>>> needs
>>>>>>>>>>>> to
>>>>>>>>>>>> be
>>>>>>>>>>>> done?
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks!
>>>>>>>>>>>>
>>>>>>>>>>>> Les
>>>>>>>>>>>>
>>>>>>>>>>>> On Mon, Dec 7, 2009 at 1:31 PM, Alan D. Cabrera
>>>>>>>>>>>> <li...@toolazydogs.com>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Dec 7, 2009, at 7:44 AM, Les Hazlewood 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.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Sounds great!
>>>>>>>>>>>>>
>>>>>>>>>>>>> The only thing that's hazy in my mind is the LGPL vetting.  I
>>>>>>>>>>>>> recall
>>>>>>>>>>>>> an
>>>>>>>>>>>>> effort to obtain permission to relicense the code from the
>>>>>>>>>>>>> original
>>>>>>>>>>>>> authors
>>>>>>>>>>>>> but am not sure if it was completed and all the requisite
>>>>>>>>>>>>> permissions
>>>>>>>>>>>>> were
>>>>>>>>>>>>> properly filed.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>> Alan
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>>
>>
>>
>

Re: Preparing for our first release

Posted by Les Hazlewood <lh...@apache.org>.

Thanks!

On Fri, Dec 18, 2009 at 4:17 PM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
> Done.
>
>
> Regards,
> Alan
>
> On Dec 18, 2009, at 1:06 PM, Les Hazlewood wrote:
>
>> In light of this, could you please resolve the following issue?
>>
>> https://issues.apache.org/jira/browse/SHIRO-41
>>
>> Thanks,
>>
>> Les
>>
>> On Wed, Dec 16, 2009 at 11:16 AM, Alan D. Cabrera <li...@toolazydogs.com>
>> wrote:
>>>
>>> For artwork it can get complicated but only if you received stipulations
>>> on
>>> its usage; it doesn't seem that there is any.  I think we're good here.
>>>
>>>
>>> Regards,
>>> Alan
>>>
>>> On Dec 16, 2009, at 7:33 AM, Les Hazlewood wrote:
>>>
>>>> There is one minor thing I forgot to mention:  Jeremy's friend created
>>>> the old JSecurity shield/lock logo for us.  He did the logo for us in
>>>> return for free website hosting on one of our servers.  This is
>>>> payment for services rendered (he payed us by doing the logo work, the
>>>> services rendered were the website hosting), so I don't think that we
>>>> need a CLA/sign-off from him.
>>>>
>>>> As I understand it, the shield/lock logo is our intellectual property
>>>> due to this agreement and we don't need to involve him.  IANAL, but I
>>>> think we're ok.
>>>>
>>>> - Les
>>>>
>>>> On Wed, Dec 16, 2009 at 10:26 AM, Les Hazlewood <lh...@apache.org>
>>>> wrote:
>>>>>
>>>>> Yep, it did.  Just for clarity's sake: every contributor on the old
>>>>> JSecurity project came over as a committer to Apache and each also
>>>>> sent the re-licensing agreement/affirmation at that time.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Les
>>>>>
>>>>> On Wed, Dec 16, 2009 at 10:22 AM, Alan D. Cabrera
>>>>> <li...@toolazydogs.com>
>>>>> wrote:
>>>>>>
>>>>>> So, back in July Craig sent out a set of emails from committers in the
>>>>>> project stating that re-licensing for ASF.  What I am not sure of is
>>>>>> that
>>>>>> this covers *all* the original authors from the JSecurity project
>>>>>> before
>>>>>> it
>>>>>> arrived at the Incubator.
>>>>>>
>>>>>>
>>>>>> Regards,
>>>>>> Alan
>>>>>>
>>>>>> On Dec 8, 2009, at 6:42 AM, Les Hazlewood wrote:
>>>>>>
>>>>>>> Craig, can you please just confirm this so we have a clear record of
>>>>>>> it?
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Les
>>>>>>>
>>>>>>> On Tue, Dec 8, 2009 at 9:26 AM, Alan D. Cabrera
>>>>>>> <li...@toolazydogs.com>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> If Craig has confirmed that all the original authors from JSecurity
>>>>>>>> have
>>>>>>>> filed a license agreement then I think we're good.
>>>>>>>>
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Alan
>>>>>>>>
>>>>>>>> On Dec 7, 2009, at 4:58 PM, Les Hazlewood wrote:
>>>>>>>>
>>>>>>>>> Yep, we're covered.  All people who contributed previously to
>>>>>>>>> JSecurity became committers to Shiro.  Before joining the
>>>>>>>>> incubator,
>>>>>>>>> we all formally (each) agreed to the transfer.
>>>>>>>>>
>>>>>>>>> HTH,
>>>>>>>>>
>>>>>>>>> Les
>>>>>>>>>
>>>>>>>>> On Mon, Dec 7, 2009 at 5:27 PM, Alan D. Cabrera
>>>>>>>>> <li...@toolazydogs.com>
>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> I recall that agreements were forwarded by current project
>>>>>>>>>> members.
>>>>>>>>>>  I'm
>>>>>>>>>> not
>>>>>>>>>> certain that we covered all the people who contributed to the
>>>>>>>>>> original
>>>>>>>>>> project.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>> Alan
>>>>>>>>>>
>>>>>>>>>> On Dec 7, 2009, at 11:40 AM, Les Hazlewood wrote:
>>>>>>>>>>
>>>>>>>>>>> To the best of my knowledge this is all finished - Craig helped
>>>>>>>>>>> out
>>>>>>>>>>> with it.  I forwarded all the formal statements from all previous
>>>>>>>>>>> committers that they fully agree and support of transferring all
>>>>>>>>>>> of
>>>>>>>>>>> their work to the ASF 2.0 license.
>>>>>>>>>>>
>>>>>>>>>>> Craig, could you please clarify if there's anything else that
>>>>>>>>>>> needs
>>>>>>>>>>> to
>>>>>>>>>>> be
>>>>>>>>>>> done?
>>>>>>>>>>>
>>>>>>>>>>> Thanks!
>>>>>>>>>>>
>>>>>>>>>>> Les
>>>>>>>>>>>
>>>>>>>>>>> On Mon, Dec 7, 2009 at 1:31 PM, Alan D. Cabrera
>>>>>>>>>>> <li...@toolazydogs.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> On Dec 7, 2009, at 7:44 AM, Les Hazlewood 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.
>>>>>>>>>>>>
>>>>>>>>>>>> Sounds great!
>>>>>>>>>>>>
>>>>>>>>>>>> The only thing that's hazy in my mind is the LGPL vetting.  I
>>>>>>>>>>>> recall
>>>>>>>>>>>> an
>>>>>>>>>>>> effort to obtain permission to relicense the code from the
>>>>>>>>>>>> original
>>>>>>>>>>>> authors
>>>>>>>>>>>> but am not sure if it was completed and all the requisite
>>>>>>>>>>>> permissions
>>>>>>>>>>>> were
>>>>>>>>>>>> properly filed.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Regards,
>>>>>>>>>>>> Alan
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>
>>>
>
>

Re: Preparing for our first release

Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.

Done.


Regards,
Alan

On Dec 18, 2009, at 1:06 PM, Les Hazlewood wrote:

> In light of this, could you please resolve the following issue?
>
> https://issues.apache.org/jira/browse/SHIRO-41
>
> Thanks,
>
> Les
>
> On Wed, Dec 16, 2009 at 11:16 AM, Alan D. Cabrera <list@toolazydogs.com 
> > wrote:
>> For artwork it can get complicated but only if you received  
>> stipulations on
>> its usage; it doesn't seem that there is any.  I think we're good  
>> here.
>>
>>
>> Regards,
>> Alan
>>
>> On Dec 16, 2009, at 7:33 AM, Les Hazlewood wrote:
>>
>>> There is one minor thing I forgot to mention:  Jeremy's friend  
>>> created
>>> the old JSecurity shield/lock logo for us.  He did the logo for us  
>>> in
>>> return for free website hosting on one of our servers.  This is
>>> payment for services rendered (he payed us by doing the logo work,  
>>> the
>>> services rendered were the website hosting), so I don't think that  
>>> we
>>> need a CLA/sign-off from him.
>>>
>>> As I understand it, the shield/lock logo is our intellectual  
>>> property
>>> due to this agreement and we don't need to involve him.  IANAL,  
>>> but I
>>> think we're ok.
>>>
>>> - Les
>>>
>>> On Wed, Dec 16, 2009 at 10:26 AM, Les Hazlewood <lhazlewood@apache.org 
>>> >
>>> wrote:
>>>>
>>>> Yep, it did.  Just for clarity's sake: every contributor on the old
>>>> JSecurity project came over as a committer to Apache and each also
>>>> sent the re-licensing agreement/affirmation at that time.
>>>>
>>>> Cheers,
>>>>
>>>> Les
>>>>
>>>> On Wed, Dec 16, 2009 at 10:22 AM, Alan D. Cabrera <list@toolazydogs.com 
>>>> >
>>>> wrote:
>>>>>
>>>>> So, back in July Craig sent out a set of emails from committers  
>>>>> in the
>>>>> project stating that re-licensing for ASF.  What I am not sure  
>>>>> of is
>>>>> that
>>>>> this covers *all* the original authors from the JSecurity  
>>>>> project before
>>>>> it
>>>>> arrived at the Incubator.
>>>>>
>>>>>
>>>>> Regards,
>>>>> Alan
>>>>>
>>>>> On Dec 8, 2009, at 6:42 AM, Les Hazlewood wrote:
>>>>>
>>>>>> Craig, can you please just confirm this so we have a clear  
>>>>>> record of
>>>>>> it?
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Les
>>>>>>
>>>>>> On Tue, Dec 8, 2009 at 9:26 AM, Alan D. Cabrera <list@toolazydogs.com 
>>>>>> >
>>>>>> wrote:
>>>>>>>
>>>>>>> If Craig has confirmed that all the original authors from  
>>>>>>> JSecurity
>>>>>>> have
>>>>>>> filed a license agreement then I think we're good.
>>>>>>>
>>>>>>>
>>>>>>> Regards,
>>>>>>> Alan
>>>>>>>
>>>>>>> On Dec 7, 2009, at 4:58 PM, Les Hazlewood wrote:
>>>>>>>
>>>>>>>> Yep, we're covered.  All people who contributed previously to
>>>>>>>> JSecurity became committers to Shiro.  Before joining the  
>>>>>>>> incubator,
>>>>>>>> we all formally (each) agreed to the transfer.
>>>>>>>>
>>>>>>>> HTH,
>>>>>>>>
>>>>>>>> Les
>>>>>>>>
>>>>>>>> On Mon, Dec 7, 2009 at 5:27 PM, Alan D. Cabrera
>>>>>>>> <li...@toolazydogs.com>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> I recall that agreements were forwarded by current project  
>>>>>>>>> members.
>>>>>>>>>  I'm
>>>>>>>>> not
>>>>>>>>> certain that we covered all the people who contributed to the
>>>>>>>>> original
>>>>>>>>> project.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Alan
>>>>>>>>>
>>>>>>>>> On Dec 7, 2009, at 11:40 AM, Les Hazlewood wrote:
>>>>>>>>>
>>>>>>>>>> To the best of my knowledge this is all finished - Craig  
>>>>>>>>>> helped out
>>>>>>>>>> with it.  I forwarded all the formal statements from all  
>>>>>>>>>> previous
>>>>>>>>>> committers that they fully agree and support of  
>>>>>>>>>> transferring all of
>>>>>>>>>> their work to the ASF 2.0 license.
>>>>>>>>>>
>>>>>>>>>> Craig, could you please clarify if there's anything else  
>>>>>>>>>> that needs
>>>>>>>>>> to
>>>>>>>>>> be
>>>>>>>>>> done?
>>>>>>>>>>
>>>>>>>>>> Thanks!
>>>>>>>>>>
>>>>>>>>>> Les
>>>>>>>>>>
>>>>>>>>>> On Mon, Dec 7, 2009 at 1:31 PM, Alan D. Cabrera
>>>>>>>>>> <li...@toolazydogs.com>
>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> On Dec 7, 2009, at 7:44 AM, Les Hazlewood 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.
>>>>>>>>>>>
>>>>>>>>>>> Sounds great!
>>>>>>>>>>>
>>>>>>>>>>> The only thing that's hazy in my mind is the LGPL  
>>>>>>>>>>> vetting.  I
>>>>>>>>>>> recall
>>>>>>>>>>> an
>>>>>>>>>>> effort to obtain permission to relicense the code from the
>>>>>>>>>>> original
>>>>>>>>>>> authors
>>>>>>>>>>> but am not sure if it was completed and all the requisite
>>>>>>>>>>> permissions
>>>>>>>>>>> were
>>>>>>>>>>> properly filed.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Regards,
>>>>>>>>>>> Alan
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>
>>
>>

Re: Preparing for our first release

Posted by Les Hazlewood <le...@anjinllc.com>.

In light of this, could you please resolve the following issue?

https://issues.apache.org/jira/browse/SHIRO-41

Thanks,

Les

On Wed, Dec 16, 2009 at 11:16 AM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
> For artwork it can get complicated but only if you received stipulations on
> its usage; it doesn't seem that there is any.  I think we're good here.
>
>
> Regards,
> Alan
>
> On Dec 16, 2009, at 7:33 AM, Les Hazlewood wrote:
>
>> There is one minor thing I forgot to mention:  Jeremy's friend created
>> the old JSecurity shield/lock logo for us.  He did the logo for us in
>> return for free website hosting on one of our servers.  This is
>> payment for services rendered (he payed us by doing the logo work, the
>> services rendered were the website hosting), so I don't think that we
>> need a CLA/sign-off from him.
>>
>> As I understand it, the shield/lock logo is our intellectual property
>> due to this agreement and we don't need to involve him.  IANAL, but I
>> think we're ok.
>>
>> - Les
>>
>> On Wed, Dec 16, 2009 at 10:26 AM, Les Hazlewood <lh...@apache.org>
>> wrote:
>>>
>>> Yep, it did.  Just for clarity's sake: every contributor on the old
>>> JSecurity project came over as a committer to Apache and each also
>>> sent the re-licensing agreement/affirmation at that time.
>>>
>>> Cheers,
>>>
>>> Les
>>>
>>> On Wed, Dec 16, 2009 at 10:22 AM, Alan D. Cabrera <li...@toolazydogs.com>
>>> wrote:
>>>>
>>>> So, back in July Craig sent out a set of emails from committers in the
>>>> project stating that re-licensing for ASF.  What I am not sure of is
>>>> that
>>>> this covers *all* the original authors from the JSecurity project before
>>>> it
>>>> arrived at the Incubator.
>>>>
>>>>
>>>> Regards,
>>>> Alan
>>>>
>>>> On Dec 8, 2009, at 6:42 AM, Les Hazlewood wrote:
>>>>
>>>>> Craig, can you please just confirm this so we have a clear record of
>>>>> it?
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Les
>>>>>
>>>>> On Tue, Dec 8, 2009 at 9:26 AM, Alan D. Cabrera <li...@toolazydogs.com>
>>>>> wrote:
>>>>>>
>>>>>> If Craig has confirmed that all the original authors from JSecurity
>>>>>> have
>>>>>> filed a license agreement then I think we're good.
>>>>>>
>>>>>>
>>>>>> Regards,
>>>>>> Alan
>>>>>>
>>>>>> On Dec 7, 2009, at 4:58 PM, Les Hazlewood wrote:
>>>>>>
>>>>>>> Yep, we're covered.  All people who contributed previously to
>>>>>>> JSecurity became committers to Shiro.  Before joining the incubator,
>>>>>>> we all formally (each) agreed to the transfer.
>>>>>>>
>>>>>>> HTH,
>>>>>>>
>>>>>>> Les
>>>>>>>
>>>>>>> On Mon, Dec 7, 2009 at 5:27 PM, Alan D. Cabrera
>>>>>>> <li...@toolazydogs.com>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> I recall that agreements were forwarded by current project members.
>>>>>>>>  I'm
>>>>>>>> not
>>>>>>>> certain that we covered all the people who contributed to the
>>>>>>>> original
>>>>>>>> project.
>>>>>>>>
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Alan
>>>>>>>>
>>>>>>>> On Dec 7, 2009, at 11:40 AM, Les Hazlewood wrote:
>>>>>>>>
>>>>>>>>> To the best of my knowledge this is all finished - Craig helped out
>>>>>>>>> with it.  I forwarded all the formal statements from all previous
>>>>>>>>> committers that they fully agree and support of transferring all of
>>>>>>>>> their work to the ASF 2.0 license.
>>>>>>>>>
>>>>>>>>> Craig, could you please clarify if there's anything else that needs
>>>>>>>>> to
>>>>>>>>> be
>>>>>>>>> done?
>>>>>>>>>
>>>>>>>>> Thanks!
>>>>>>>>>
>>>>>>>>> Les
>>>>>>>>>
>>>>>>>>> On Mon, Dec 7, 2009 at 1:31 PM, Alan D. Cabrera
>>>>>>>>> <li...@toolazydogs.com>
>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> On Dec 7, 2009, at 7:44 AM, Les Hazlewood 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.
>>>>>>>>>>
>>>>>>>>>> Sounds great!
>>>>>>>>>>
>>>>>>>>>> The only thing that's hazy in my mind is the LGPL vetting.  I
>>>>>>>>>> recall
>>>>>>>>>> an
>>>>>>>>>> effort to obtain permission to relicense the code from the
>>>>>>>>>> original
>>>>>>>>>> authors
>>>>>>>>>> but am not sure if it was completed and all the requisite
>>>>>>>>>> permissions
>>>>>>>>>> were
>>>>>>>>>> properly filed.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>> Alan
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>
>
>

Re: Preparing for our first release

Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.

For artwork it can get complicated but only if you received  
stipulations on its usage; it doesn't seem that there is any.  I think  
we're good here.


Regards,
Alan

On Dec 16, 2009, at 7:33 AM, Les Hazlewood wrote:

> There is one minor thing I forgot to mention:  Jeremy's friend created
> the old JSecurity shield/lock logo for us.  He did the logo for us in
> return for free website hosting on one of our servers.  This is
> payment for services rendered (he payed us by doing the logo work, the
> services rendered were the website hosting), so I don't think that we
> need a CLA/sign-off from him.
>
> As I understand it, the shield/lock logo is our intellectual property
> due to this agreement and we don't need to involve him.  IANAL, but I
> think we're ok.
>
> - Les
>
> On Wed, Dec 16, 2009 at 10:26 AM, Les Hazlewood  
> <lh...@apache.org> wrote:
>> Yep, it did.  Just for clarity's sake: every contributor on the old
>> JSecurity project came over as a committer to Apache and each also
>> sent the re-licensing agreement/affirmation at that time.
>>
>> Cheers,
>>
>> Les
>>
>> On Wed, Dec 16, 2009 at 10:22 AM, Alan D. Cabrera <list@toolazydogs.com 
>> > wrote:
>>> So, back in July Craig sent out a set of emails from committers in  
>>> the
>>> project stating that re-licensing for ASF.  What I am not sure of  
>>> is that
>>> this covers *all* the original authors from the JSecurity project  
>>> before it
>>> arrived at the Incubator.
>>>
>>>
>>> Regards,
>>> Alan
>>>
>>> On Dec 8, 2009, at 6:42 AM, Les Hazlewood wrote:
>>>
>>>> Craig, can you please just confirm this so we have a clear record  
>>>> of it?
>>>>
>>>> Thanks,
>>>>
>>>> Les
>>>>
>>>> On Tue, Dec 8, 2009 at 9:26 AM, Alan D. Cabrera <list@toolazydogs.com 
>>>> >
>>>> wrote:
>>>>>
>>>>> If Craig has confirmed that all the original authors from  
>>>>> JSecurity have
>>>>> filed a license agreement then I think we're good.
>>>>>
>>>>>
>>>>> Regards,
>>>>> Alan
>>>>>
>>>>> On Dec 7, 2009, at 4:58 PM, Les Hazlewood wrote:
>>>>>
>>>>>> Yep, we're covered.  All people who contributed previously to
>>>>>> JSecurity became committers to Shiro.  Before joining the  
>>>>>> incubator,
>>>>>> we all formally (each) agreed to the transfer.
>>>>>>
>>>>>> HTH,
>>>>>>
>>>>>> Les
>>>>>>
>>>>>> On Mon, Dec 7, 2009 at 5:27 PM, Alan D. Cabrera <list@toolazydogs.com 
>>>>>> >
>>>>>> wrote:
>>>>>>>
>>>>>>> I recall that agreements were forwarded by current project  
>>>>>>> members.
>>>>>>>  I'm
>>>>>>> not
>>>>>>> certain that we covered all the people who contributed to the  
>>>>>>> original
>>>>>>> project.
>>>>>>>
>>>>>>>
>>>>>>> Regards,
>>>>>>> Alan
>>>>>>>
>>>>>>> On Dec 7, 2009, at 11:40 AM, Les Hazlewood wrote:
>>>>>>>
>>>>>>>> To the best of my knowledge this is all finished - Craig  
>>>>>>>> helped out
>>>>>>>> with it.  I forwarded all the formal statements from all  
>>>>>>>> previous
>>>>>>>> committers that they fully agree and support of transferring  
>>>>>>>> all of
>>>>>>>> their work to the ASF 2.0 license.
>>>>>>>>
>>>>>>>> Craig, could you please clarify if there's anything else that  
>>>>>>>> needs to
>>>>>>>> be
>>>>>>>> done?
>>>>>>>>
>>>>>>>> Thanks!
>>>>>>>>
>>>>>>>> Les
>>>>>>>>
>>>>>>>> On Mon, Dec 7, 2009 at 1:31 PM, Alan D. Cabrera <list@toolazydogs.com 
>>>>>>>> >
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> On Dec 7, 2009, at 7:44 AM, Les Hazlewood 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.
>>>>>>>>>
>>>>>>>>> Sounds great!
>>>>>>>>>
>>>>>>>>> The only thing that's hazy in my mind is the LGPL vetting.   
>>>>>>>>> I recall
>>>>>>>>> an
>>>>>>>>> effort to obtain permission to relicense the code from the  
>>>>>>>>> original
>>>>>>>>> authors
>>>>>>>>> but am not sure if it was completed and all the requisite  
>>>>>>>>> permissions
>>>>>>>>> were
>>>>>>>>> properly filed.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Alan
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>
>>>
>>

Re: Preparing for our first release

Posted by Les Hazlewood <lh...@apache.org>.

There is one minor thing I forgot to mention:  Jeremy's friend created
the old JSecurity shield/lock logo for us.  He did the logo for us in
return for free website hosting on one of our servers.  This is
payment for services rendered (he payed us by doing the logo work, the
services rendered were the website hosting), so I don't think that we
need a CLA/sign-off from him.

As I understand it, the shield/lock logo is our intellectual property
due to this agreement and we don't need to involve him.  IANAL, but I
think we're ok.

- Les

On Wed, Dec 16, 2009 at 10:26 AM, Les Hazlewood <lh...@apache.org> wrote:
> Yep, it did.  Just for clarity's sake: every contributor on the old
> JSecurity project came over as a committer to Apache and each also
> sent the re-licensing agreement/affirmation at that time.
>
> Cheers,
>
> Les
>
> On Wed, Dec 16, 2009 at 10:22 AM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>> So, back in July Craig sent out a set of emails from committers in the
>> project stating that re-licensing for ASF.  What I am not sure of is that
>> this covers *all* the original authors from the JSecurity project before it
>> arrived at the Incubator.
>>
>>
>> Regards,
>> Alan
>>
>> On Dec 8, 2009, at 6:42 AM, Les Hazlewood wrote:
>>
>>> Craig, can you please just confirm this so we have a clear record of it?
>>>
>>> Thanks,
>>>
>>> Les
>>>
>>> On Tue, Dec 8, 2009 at 9:26 AM, Alan D. Cabrera <li...@toolazydogs.com>
>>> wrote:
>>>>
>>>> If Craig has confirmed that all the original authors from JSecurity have
>>>> filed a license agreement then I think we're good.
>>>>
>>>>
>>>> Regards,
>>>> Alan
>>>>
>>>> On Dec 7, 2009, at 4:58 PM, Les Hazlewood wrote:
>>>>
>>>>> Yep, we're covered.  All people who contributed previously to
>>>>> JSecurity became committers to Shiro.  Before joining the incubator,
>>>>> we all formally (each) agreed to the transfer.
>>>>>
>>>>> HTH,
>>>>>
>>>>> Les
>>>>>
>>>>> On Mon, Dec 7, 2009 at 5:27 PM, Alan D. Cabrera <li...@toolazydogs.com>
>>>>> wrote:
>>>>>>
>>>>>> I recall that agreements were forwarded by current project members.
>>>>>>  I'm
>>>>>> not
>>>>>> certain that we covered all the people who contributed to the original
>>>>>> project.
>>>>>>
>>>>>>
>>>>>> Regards,
>>>>>> Alan
>>>>>>
>>>>>> On Dec 7, 2009, at 11:40 AM, Les Hazlewood wrote:
>>>>>>
>>>>>>> To the best of my knowledge this is all finished - Craig helped out
>>>>>>> with it.  I forwarded all the formal statements from all previous
>>>>>>> committers that they fully agree and support of transferring all of
>>>>>>> their work to the ASF 2.0 license.
>>>>>>>
>>>>>>> Craig, could you please clarify if there's anything else that needs to
>>>>>>> be
>>>>>>> done?
>>>>>>>
>>>>>>> Thanks!
>>>>>>>
>>>>>>> Les
>>>>>>>
>>>>>>> On Mon, Dec 7, 2009 at 1:31 PM, Alan D. Cabrera <li...@toolazydogs.com>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> On Dec 7, 2009, at 7:44 AM, Les Hazlewood 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.
>>>>>>>>
>>>>>>>> Sounds great!
>>>>>>>>
>>>>>>>> The only thing that's hazy in my mind is the LGPL vetting.  I recall
>>>>>>>> an
>>>>>>>> effort to obtain permission to relicense the code from the original
>>>>>>>> authors
>>>>>>>> but am not sure if it was completed and all the requisite permissions
>>>>>>>> were
>>>>>>>> properly filed.
>>>>>>>>
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Alan
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>
>>
>

Re: Preparing for our first release

Posted by Les Hazlewood <le...@anjinllc.com>.

Yep, that's correct!

On Wed, Dec 16, 2009 at 11:15 AM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
> So, just to put the nail into this coffin, this is the exhaustive list
> developers from the pre-Incubator project:
>
>> Peter Ledbrook
>> Jeremy Haile
>> Allan Ditzel
>> Tim Veil
>> Les Hazlewood
>
> Am I correct?
>
> Regards,
> Alan
>
>
> On Dec 16, 2009, at 7:26 AM, Les Hazlewood wrote:
>
>> Yep, it did.  Just for clarity's sake: every contributor on the old
>> JSecurity project came over as a committer to Apache and each also
>> sent the re-licensing agreement/affirmation at that time.
>>
>> Cheers,
>>
>> Les
>>
>> On Wed, Dec 16, 2009 at 10:22 AM, Alan D. Cabrera <li...@toolazydogs.com>
>> wrote:
>>>
>>> So, back in July Craig sent out a set of emails from committers in the
>>> project stating that re-licensing for ASF.  What I am not sure of is that
>>> this covers *all* the original authors from the JSecurity project before
>>> it
>>> arrived at the Incubator.
>>>
>>>
>>> Regards,
>>> Alan
>>>
>>> On Dec 8, 2009, at 6:42 AM, Les Hazlewood wrote:
>>>
>>>> Craig, can you please just confirm this so we have a clear record of it?
>>>>
>>>> Thanks,
>>>>
>>>> Les
>>>>
>>>> On Tue, Dec 8, 2009 at 9:26 AM, Alan D. Cabrera <li...@toolazydogs.com>
>>>> wrote:
>>>>>
>>>>> If Craig has confirmed that all the original authors from JSecurity
>>>>> have
>>>>> filed a license agreement then I think we're good.
>>>>>
>>>>>
>>>>> Regards,
>>>>> Alan
>>>>>
>>>>> On Dec 7, 2009, at 4:58 PM, Les Hazlewood wrote:
>>>>>
>>>>>> Yep, we're covered.  All people who contributed previously to
>>>>>> JSecurity became committers to Shiro.  Before joining the incubator,
>>>>>> we all formally (each) agreed to the transfer.
>>>>>>
>>>>>> HTH,
>>>>>>
>>>>>> Les
>>>>>>
>>>>>> On Mon, Dec 7, 2009 at 5:27 PM, Alan D. Cabrera <li...@toolazydogs.com>
>>>>>> wrote:
>>>>>>>
>>>>>>> I recall that agreements were forwarded by current project members.
>>>>>>>  I'm
>>>>>>> not
>>>>>>> certain that we covered all the people who contributed to the
>>>>>>> original
>>>>>>> project.
>>>>>>>
>>>>>>>
>>>>>>> Regards,
>>>>>>> Alan
>>>>>>>
>>>>>>> On Dec 7, 2009, at 11:40 AM, Les Hazlewood wrote:
>>>>>>>
>>>>>>>> To the best of my knowledge this is all finished - Craig helped out
>>>>>>>> with it.  I forwarded all the formal statements from all previous
>>>>>>>> committers that they fully agree and support of transferring all of
>>>>>>>> their work to the ASF 2.0 license.
>>>>>>>>
>>>>>>>> Craig, could you please clarify if there's anything else that needs
>>>>>>>> to
>>>>>>>> be
>>>>>>>> done?
>>>>>>>>
>>>>>>>> Thanks!
>>>>>>>>
>>>>>>>> Les
>>>>>>>>
>>>>>>>> On Mon, Dec 7, 2009 at 1:31 PM, Alan D. Cabrera
>>>>>>>> <li...@toolazydogs.com>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> On Dec 7, 2009, at 7:44 AM, Les Hazlewood 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.
>>>>>>>>>
>>>>>>>>> Sounds great!
>>>>>>>>>
>>>>>>>>> The only thing that's hazy in my mind is the LGPL vetting.  I
>>>>>>>>> recall
>>>>>>>>> an
>>>>>>>>> effort to obtain permission to relicense the code from the original
>>>>>>>>> authors
>>>>>>>>> but am not sure if it was completed and all the requisite
>>>>>>>>> permissions
>>>>>>>>> were
>>>>>>>>> properly filed.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Alan
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>
>>>
>
>

Re: Preparing for our first release

Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.

So, just to put the nail into this coffin, this is the exhaustive list  
developers from the pre-Incubator project:

> Peter Ledbrook
> Jeremy Haile
> Allan Ditzel
> Tim Veil
> Les Hazlewood

Am I correct?

Regards,
Alan


On Dec 16, 2009, at 7:26 AM, Les Hazlewood wrote:

> Yep, it did.  Just for clarity's sake: every contributor on the old
> JSecurity project came over as a committer to Apache and each also
> sent the re-licensing agreement/affirmation at that time.
>
> Cheers,
>
> Les
>
> On Wed, Dec 16, 2009 at 10:22 AM, Alan D. Cabrera <list@toolazydogs.com 
> > wrote:
>> So, back in July Craig sent out a set of emails from committers in  
>> the
>> project stating that re-licensing for ASF.  What I am not sure of  
>> is that
>> this covers *all* the original authors from the JSecurity project  
>> before it
>> arrived at the Incubator.
>>
>>
>> Regards,
>> Alan
>>
>> On Dec 8, 2009, at 6:42 AM, Les Hazlewood wrote:
>>
>>> Craig, can you please just confirm this so we have a clear record  
>>> of it?
>>>
>>> Thanks,
>>>
>>> Les
>>>
>>> On Tue, Dec 8, 2009 at 9:26 AM, Alan D. Cabrera <list@toolazydogs.com 
>>> >
>>> wrote:
>>>>
>>>> If Craig has confirmed that all the original authors from  
>>>> JSecurity have
>>>> filed a license agreement then I think we're good.
>>>>
>>>>
>>>> Regards,
>>>> Alan
>>>>
>>>> On Dec 7, 2009, at 4:58 PM, Les Hazlewood wrote:
>>>>
>>>>> Yep, we're covered.  All people who contributed previously to
>>>>> JSecurity became committers to Shiro.  Before joining the  
>>>>> incubator,
>>>>> we all formally (each) agreed to the transfer.
>>>>>
>>>>> HTH,
>>>>>
>>>>> Les
>>>>>
>>>>> On Mon, Dec 7, 2009 at 5:27 PM, Alan D. Cabrera <list@toolazydogs.com 
>>>>> >
>>>>> wrote:
>>>>>>
>>>>>> I recall that agreements were forwarded by current project  
>>>>>> members.
>>>>>>  I'm
>>>>>> not
>>>>>> certain that we covered all the people who contributed to the  
>>>>>> original
>>>>>> project.
>>>>>>
>>>>>>
>>>>>> Regards,
>>>>>> Alan
>>>>>>
>>>>>> On Dec 7, 2009, at 11:40 AM, Les Hazlewood wrote:
>>>>>>
>>>>>>> To the best of my knowledge this is all finished - Craig  
>>>>>>> helped out
>>>>>>> with it.  I forwarded all the formal statements from all  
>>>>>>> previous
>>>>>>> committers that they fully agree and support of transferring  
>>>>>>> all of
>>>>>>> their work to the ASF 2.0 license.
>>>>>>>
>>>>>>> Craig, could you please clarify if there's anything else that  
>>>>>>> needs to
>>>>>>> be
>>>>>>> done?
>>>>>>>
>>>>>>> Thanks!
>>>>>>>
>>>>>>> Les
>>>>>>>
>>>>>>> On Mon, Dec 7, 2009 at 1:31 PM, Alan D. Cabrera <list@toolazydogs.com 
>>>>>>> >
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> On Dec 7, 2009, at 7:44 AM, Les Hazlewood 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.
>>>>>>>>
>>>>>>>> Sounds great!
>>>>>>>>
>>>>>>>> The only thing that's hazy in my mind is the LGPL vetting.  I  
>>>>>>>> recall
>>>>>>>> an
>>>>>>>> effort to obtain permission to relicense the code from the  
>>>>>>>> original
>>>>>>>> authors
>>>>>>>> but am not sure if it was completed and all the requisite  
>>>>>>>> permissions
>>>>>>>> were
>>>>>>>> properly filed.
>>>>>>>>
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Alan
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>
>>

Re: Preparing for our first release

Posted by Les Hazlewood <lh...@apache.org>.

Yep, it did.  Just for clarity's sake: every contributor on the old
JSecurity project came over as a committer to Apache and each also
sent the re-licensing agreement/affirmation at that time.

Cheers,

Les

On Wed, Dec 16, 2009 at 10:22 AM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
> So, back in July Craig sent out a set of emails from committers in the
> project stating that re-licensing for ASF.  What I am not sure of is that
> this covers *all* the original authors from the JSecurity project before it
> arrived at the Incubator.
>
>
> Regards,
> Alan
>
> On Dec 8, 2009, at 6:42 AM, Les Hazlewood wrote:
>
>> Craig, can you please just confirm this so we have a clear record of it?
>>
>> Thanks,
>>
>> Les
>>
>> On Tue, Dec 8, 2009 at 9:26 AM, Alan D. Cabrera <li...@toolazydogs.com>
>> wrote:
>>>
>>> If Craig has confirmed that all the original authors from JSecurity have
>>> filed a license agreement then I think we're good.
>>>
>>>
>>> Regards,
>>> Alan
>>>
>>> On Dec 7, 2009, at 4:58 PM, Les Hazlewood wrote:
>>>
>>>> Yep, we're covered.  All people who contributed previously to
>>>> JSecurity became committers to Shiro.  Before joining the incubator,
>>>> we all formally (each) agreed to the transfer.
>>>>
>>>> HTH,
>>>>
>>>> Les
>>>>
>>>> On Mon, Dec 7, 2009 at 5:27 PM, Alan D. Cabrera <li...@toolazydogs.com>
>>>> wrote:
>>>>>
>>>>> I recall that agreements were forwarded by current project members.
>>>>>  I'm
>>>>> not
>>>>> certain that we covered all the people who contributed to the original
>>>>> project.
>>>>>
>>>>>
>>>>> Regards,
>>>>> Alan
>>>>>
>>>>> On Dec 7, 2009, at 11:40 AM, Les Hazlewood wrote:
>>>>>
>>>>>> To the best of my knowledge this is all finished - Craig helped out
>>>>>> with it.  I forwarded all the formal statements from all previous
>>>>>> committers that they fully agree and support of transferring all of
>>>>>> their work to the ASF 2.0 license.
>>>>>>
>>>>>> Craig, could you please clarify if there's anything else that needs to
>>>>>> be
>>>>>> done?
>>>>>>
>>>>>> Thanks!
>>>>>>
>>>>>> Les
>>>>>>
>>>>>> On Mon, Dec 7, 2009 at 1:31 PM, Alan D. Cabrera <li...@toolazydogs.com>
>>>>>> wrote:
>>>>>>>
>>>>>>> On Dec 7, 2009, at 7:44 AM, Les Hazlewood 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.
>>>>>>>
>>>>>>> Sounds great!
>>>>>>>
>>>>>>> The only thing that's hazy in my mind is the LGPL vetting.  I recall
>>>>>>> an
>>>>>>> effort to obtain permission to relicense the code from the original
>>>>>>> authors
>>>>>>> but am not sure if it was completed and all the requisite permissions
>>>>>>> were
>>>>>>> properly filed.
>>>>>>>
>>>>>>>
>>>>>>> Regards,
>>>>>>> Alan
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>
>>>
>
>

Re: Preparing for our first release

Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.

So, back in July Craig sent out a set of emails from committers in the  
project stating that re-licensing for ASF.  What I am not sure of is  
that this covers *all* the original authors from the JSecurity project  
before it arrived at the Incubator.


Regards,
Alan

On Dec 8, 2009, at 6:42 AM, Les Hazlewood wrote:

> Craig, can you please just confirm this so we have a clear record of  
> it?
>
> Thanks,
>
> Les
>
> On Tue, Dec 8, 2009 at 9:26 AM, Alan D. Cabrera  
> <li...@toolazydogs.com> wrote:
>> If Craig has confirmed that all the original authors from JSecurity  
>> have
>> filed a license agreement then I think we're good.
>>
>>
>> Regards,
>> Alan
>>
>> On Dec 7, 2009, at 4:58 PM, Les Hazlewood wrote:
>>
>>> Yep, we're covered.  All people who contributed previously to
>>> JSecurity became committers to Shiro.  Before joining the incubator,
>>> we all formally (each) agreed to the transfer.
>>>
>>> HTH,
>>>
>>> Les
>>>
>>> On Mon, Dec 7, 2009 at 5:27 PM, Alan D. Cabrera <list@toolazydogs.com 
>>> >
>>> wrote:
>>>>
>>>> I recall that agreements were forwarded by current project  
>>>> members.  I'm
>>>> not
>>>> certain that we covered all the people who contributed to the  
>>>> original
>>>> project.
>>>>
>>>>
>>>> Regards,
>>>> Alan
>>>>
>>>> On Dec 7, 2009, at 11:40 AM, Les Hazlewood wrote:
>>>>
>>>>> To the best of my knowledge this is all finished - Craig helped  
>>>>> out
>>>>> with it.  I forwarded all the formal statements from all previous
>>>>> committers that they fully agree and support of transferring all  
>>>>> of
>>>>> their work to the ASF 2.0 license.
>>>>>
>>>>> Craig, could you please clarify if there's anything else that  
>>>>> needs to
>>>>> be
>>>>> done?
>>>>>
>>>>> Thanks!
>>>>>
>>>>> Les
>>>>>
>>>>> On Mon, Dec 7, 2009 at 1:31 PM, Alan D. Cabrera <list@toolazydogs.com 
>>>>> >
>>>>> wrote:
>>>>>>
>>>>>> On Dec 7, 2009, at 7:44 AM, Les Hazlewood 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.
>>>>>>
>>>>>> Sounds great!
>>>>>>
>>>>>> The only thing that's hazy in my mind is the LGPL vetting.  I  
>>>>>> recall an
>>>>>> effort to obtain permission to relicense the code from the  
>>>>>> original
>>>>>> authors
>>>>>> but am not sure if it was completed and all the requisite  
>>>>>> permissions
>>>>>> were
>>>>>> properly filed.
>>>>>>
>>>>>>
>>>>>> Regards,
>>>>>> Alan
>>>>>>
>>>>>>
>>>>
>>>>
>>
>>

Re: Preparing for our first release

Posted by Les Hazlewood <lh...@apache.org>.

Craig, can you please just confirm this so we have a clear record of it?

Thanks,

Les

On Tue, Dec 8, 2009 at 9:26 AM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
> If Craig has confirmed that all the original authors from JSecurity have
> filed a license agreement then I think we're good.
>
>
> Regards,
> Alan
>
> On Dec 7, 2009, at 4:58 PM, Les Hazlewood wrote:
>
>> Yep, we're covered.  All people who contributed previously to
>> JSecurity became committers to Shiro.  Before joining the incubator,
>> we all formally (each) agreed to the transfer.
>>
>> HTH,
>>
>> Les
>>
>> On Mon, Dec 7, 2009 at 5:27 PM, Alan D. Cabrera <li...@toolazydogs.com>
>> wrote:
>>>
>>> I recall that agreements were forwarded by current project members.  I'm
>>> not
>>> certain that we covered all the people who contributed to the original
>>> project.
>>>
>>>
>>> Regards,
>>> Alan
>>>
>>> On Dec 7, 2009, at 11:40 AM, Les Hazlewood wrote:
>>>
>>>> To the best of my knowledge this is all finished - Craig helped out
>>>> with it.  I forwarded all the formal statements from all previous
>>>> committers that they fully agree and support of transferring all of
>>>> their work to the ASF 2.0 license.
>>>>
>>>> Craig, could you please clarify if there's anything else that needs to
>>>> be
>>>> done?
>>>>
>>>> Thanks!
>>>>
>>>> Les
>>>>
>>>> On Mon, Dec 7, 2009 at 1:31 PM, Alan D. Cabrera <li...@toolazydogs.com>
>>>> wrote:
>>>>>
>>>>> On Dec 7, 2009, at 7:44 AM, Les Hazlewood 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.
>>>>>
>>>>> Sounds great!
>>>>>
>>>>> The only thing that's hazy in my mind is the LGPL vetting.  I recall an
>>>>> effort to obtain permission to relicense the code from the original
>>>>> authors
>>>>> but am not sure if it was completed and all the requisite permissions
>>>>> were
>>>>> properly filed.
>>>>>
>>>>>
>>>>> Regards,
>>>>> Alan
>>>>>
>>>>>
>>>
>>>
>
>

Re: Preparing for our first release

Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.

If Craig has confirmed that all the original authors from JSecurity  
have filed a license agreement then I think we're good.


Regards,
Alan

On Dec 7, 2009, at 4:58 PM, Les Hazlewood wrote:

> Yep, we're covered.  All people who contributed previously to
> JSecurity became committers to Shiro.  Before joining the incubator,
> we all formally (each) agreed to the transfer.
>
> HTH,
>
> Les
>
> On Mon, Dec 7, 2009 at 5:27 PM, Alan D. Cabrera  
> <li...@toolazydogs.com> wrote:
>> I recall that agreements were forwarded by current project  
>> members.  I'm not
>> certain that we covered all the people who contributed to the  
>> original
>> project.
>>
>>
>> Regards,
>> Alan
>>
>> On Dec 7, 2009, at 11:40 AM, Les Hazlewood wrote:
>>
>>> To the best of my knowledge this is all finished - Craig helped out
>>> with it.  I forwarded all the formal statements from all previous
>>> committers that they fully agree and support of transferring all of
>>> their work to the ASF 2.0 license.
>>>
>>> Craig, could you please clarify if there's anything else that  
>>> needs to be
>>> done?
>>>
>>> Thanks!
>>>
>>> Les
>>>
>>> On Mon, Dec 7, 2009 at 1:31 PM, Alan D. Cabrera <list@toolazydogs.com 
>>> >
>>> wrote:
>>>>
>>>> On Dec 7, 2009, at 7:44 AM, Les Hazlewood 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.
>>>>
>>>> Sounds great!
>>>>
>>>> The only thing that's hazy in my mind is the LGPL vetting.  I  
>>>> recall an
>>>> effort to obtain permission to relicense the code from the original
>>>> authors
>>>> but am not sure if it was completed and all the requisite  
>>>> permissions
>>>> were
>>>> properly filed.
>>>>
>>>>
>>>> Regards,
>>>> Alan
>>>>
>>>>
>>
>>

Re: Preparing for our first release

Posted by Les Hazlewood <lh...@apache.org>.

Yep, we're covered.  All people who contributed previously to
JSecurity became committers to Shiro.  Before joining the incubator,
we all formally (each) agreed to the transfer.

HTH,

Les

On Mon, Dec 7, 2009 at 5:27 PM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
> I recall that agreements were forwarded by current project members.  I'm not
> certain that we covered all the people who contributed to the original
> project.
>
>
> Regards,
> Alan
>
> On Dec 7, 2009, at 11:40 AM, Les Hazlewood wrote:
>
>> To the best of my knowledge this is all finished - Craig helped out
>> with it.  I forwarded all the formal statements from all previous
>> committers that they fully agree and support of transferring all of
>> their work to the ASF 2.0 license.
>>
>> Craig, could you please clarify if there's anything else that needs to be
>> done?
>>
>> Thanks!
>>
>> Les
>>
>> On Mon, Dec 7, 2009 at 1:31 PM, Alan D. Cabrera <li...@toolazydogs.com>
>> wrote:
>>>
>>> On Dec 7, 2009, at 7:44 AM, Les Hazlewood 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.
>>>
>>> Sounds great!
>>>
>>> The only thing that's hazy in my mind is the LGPL vetting.  I recall an
>>> effort to obtain permission to relicense the code from the original
>>> authors
>>> but am not sure if it was completed and all the requisite permissions
>>> were
>>> properly filed.
>>>
>>>
>>> Regards,
>>> Alan
>>>
>>>
>
>

Re: Preparing for our first release

Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.

I recall that agreements were forwarded by current project members.   
I'm not certain that we covered all the people who contributed to the  
original project.


Regards,
Alan

On Dec 7, 2009, at 11:40 AM, Les Hazlewood wrote:

> To the best of my knowledge this is all finished - Craig helped out
> with it.  I forwarded all the formal statements from all previous
> committers that they fully agree and support of transferring all of
> their work to the ASF 2.0 license.
>
> Craig, could you please clarify if there's anything else that needs  
> to be done?
>
> Thanks!
>
> Les
>
> On Mon, Dec 7, 2009 at 1:31 PM, Alan D. Cabrera  
> <li...@toolazydogs.com> wrote:
>>
>> On Dec 7, 2009, at 7:44 AM, Les Hazlewood 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.
>>
>> Sounds great!
>>
>> The only thing that's hazy in my mind is the LGPL vetting.  I  
>> recall an
>> effort to obtain permission to relicense the code from the original  
>> authors
>> but am not sure if it was completed and all the requisite  
>> permissions were
>> properly filed.
>>
>>
>> Regards,
>> Alan
>>
>>

Re: Preparing for our first release

Posted by Les Hazlewood <lh...@apache.org>.

To the best of my knowledge this is all finished - Craig helped out
with it.  I forwarded all the formal statements from all previous
committers that they fully agree and support of transferring all of
their work to the ASF 2.0 license.

Craig, could you please clarify if there's anything else that needs to be done?

Thanks!

Les

On Mon, Dec 7, 2009 at 1:31 PM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>
> On Dec 7, 2009, at 7:44 AM, Les Hazlewood 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.
>
> Sounds great!
>
> The only thing that's hazy in my mind is the LGPL vetting.  I recall an
> effort to obtain permission to relicense the code from the original authors
> but am not sure if it was completed and all the requisite permissions were
> properly filed.
>
>
> Regards,
> Alan
>
>

Re: Preparing for our first release

Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.

On Dec 7, 2009, at 7:44 AM, Les Hazlewood 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.

Sounds great!

The only thing that's hazy in my mind is the LGPL vetting.  I recall  
an effort to obtain permission to relicense the code from the original  
authors but am not sure if it was completed and all the requisite  
permissions were properly filed.


Regards,
Alan

Re: Preparing for our first release

Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.

my 2cents: makes sense to me.

On Dec 7, 2009, at 2:15 PM, Kalle Korhonen wrote:

> I do everything lazily :) - the cost of creating the branch is the
> same and it's not clear we ever need to pay that cost, so why pay it
> upfront. If we had a roadmap that would dictate the features that go
> into 1.1, then sure, we should create the branch as well. Until then,
> it's all bug fixes. "Many tags, few branches", that's my motto.
>
> Kalle
>
>
> On Mon, Dec 7, 2009 at 2:03 PM, Les Hazlewood  
> <lh...@apache.org> wrote:
>> Yep, this is exactly what we do at work for all of our releases.  It
>> works quite well.
>>
>> In practice, we always tag every release and only create a branch if
>> there are bugs reported against a previous release.  If there is no
>> branch at the time an issue is reported, we create one at that time
>> off of the tag and then do our bug fixes in this 'lazily-created'
>> branch.
>>
>> The only benefit this provides is that the number of branches tends  
>> to
>> be smaller over time, making it easier to browse the SVN branches
>> directory.  But I certainly have no problems with always creating a
>> branch no matter what if that's what people prefer.  Any preferences?
>>
>> Les
>>
>> On Mon, Dec 7, 2009 at 3:40 PM, Kalle Korhonen
>> <ka...@gmail.com> wrote:
>>> On Mon, Dec 7, 2009 at 12:23 PM, Alan D. Cabrera <list@toolazydogs.com 
>>> > wrote:
>>>> If one uses a branch name branches/1.x and let's say that 1.0,  
>>>> 1.1, and 1.2
>>>> have been released, what do you do when you need to patch 1.1?   
>>>> When you
>>>
>>> When 1.1.0 is released, a 1.1.x branch is created (or it's created
>>> later from 1.1.0 tag when needed). Once we release 1.0.0, we could
>>> either immediately create 1.0.x branch and prepare trunk for 1.1.0
>>> development, or we prepare trunk for 1.0.1 development and branch  
>>> the
>>> same way later as needed.
>>>
>>>> make this 1.x branch what goes into trunk?
>>>
>>> If there's a 1.x branch, it implies that trunk has already moved to
>>> 2.x (following the release branch pattern - the version "farthest  
>>> out"
>>> is in the trunk). The x in the branch name denotes "the trunk for  
>>> all
>>> versions of <version>.x"
>>>
>>> Kalle
>>>
>>

Re: Preparing for our first release

Posted by Kalle Korhonen <ka...@gmail.com>.

I do everything lazily :) - the cost of creating the branch is the
same and it's not clear we ever need to pay that cost, so why pay it
upfront. If we had a roadmap that would dictate the features that go
into 1.1, then sure, we should create the branch as well. Until then,
it's all bug fixes. "Many tags, few branches", that's my motto.

Kalle


On Mon, Dec 7, 2009 at 2:03 PM, Les Hazlewood <lh...@apache.org> wrote:
> Yep, this is exactly what we do at work for all of our releases.  It
> works quite well.
>
> In practice, we always tag every release and only create a branch if
> there are bugs reported against a previous release.  If there is no
> branch at the time an issue is reported, we create one at that time
> off of the tag and then do our bug fixes in this 'lazily-created'
> branch.
>
> The only benefit this provides is that the number of branches tends to
> be smaller over time, making it easier to browse the SVN branches
> directory.  But I certainly have no problems with always creating a
> branch no matter what if that's what people prefer.  Any preferences?
>
> Les
>
> On Mon, Dec 7, 2009 at 3:40 PM, Kalle Korhonen
> <ka...@gmail.com> wrote:
>> On Mon, Dec 7, 2009 at 12:23 PM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>>> If one uses a branch name branches/1.x and let's say that 1.0, 1.1, and 1.2
>>> have been released, what do you do when you need to patch 1.1?  When you
>>
>> When 1.1.0 is released, a 1.1.x branch is created (or it's created
>> later from 1.1.0 tag when needed). Once we release 1.0.0, we could
>> either immediately create 1.0.x branch and prepare trunk for 1.1.0
>> development, or we prepare trunk for 1.0.1 development and branch the
>> same way later as needed.
>>
>>> make this 1.x branch what goes into trunk?
>>
>> If there's a 1.x branch, it implies that trunk has already moved to
>> 2.x (following the release branch pattern - the version "farthest out"
>> is in the trunk). The x in the branch name denotes "the trunk for all
>> versions of <version>.x"
>>
>> Kalle
>>
>

Re: Preparing for our first release

Posted by Les Hazlewood <lh...@apache.org>.

Yep, this is exactly what we do at work for all of our releases.  It
works quite well.

In practice, we always tag every release and only create a branch if
there are bugs reported against a previous release.  If there is no
branch at the time an issue is reported, we create one at that time
off of the tag and then do our bug fixes in this 'lazily-created'
branch.

The only benefit this provides is that the number of branches tends to
be smaller over time, making it easier to browse the SVN branches
directory.  But I certainly have no problems with always creating a
branch no matter what if that's what people prefer.  Any preferences?

Les

On Mon, Dec 7, 2009 at 3:40 PM, Kalle Korhonen
<ka...@gmail.com> wrote:
> On Mon, Dec 7, 2009 at 12:23 PM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>> If one uses a branch name branches/1.x and let's say that 1.0, 1.1, and 1.2
>> have been released, what do you do when you need to patch 1.1?  When you
>
> When 1.1.0 is released, a 1.1.x branch is created (or it's created
> later from 1.1.0 tag when needed). Once we release 1.0.0, we could
> either immediately create 1.0.x branch and prepare trunk for 1.1.0
> development, or we prepare trunk for 1.0.1 development and branch the
> same way later as needed.
>
>> make this 1.x branch what goes into trunk?
>
> If there's a 1.x branch, it implies that trunk has already moved to
> 2.x (following the release branch pattern - the version "farthest out"
> is in the trunk). The x in the branch name denotes "the trunk for all
> versions of <version>.x"
>
> Kalle
>

Re: Preparing for our first release

Posted by Kalle Korhonen <ka...@gmail.com>.

On Mon, Dec 7, 2009 at 12:23 PM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
> If one uses a branch name branches/1.x and let's say that 1.0, 1.1, and 1.2
> have been released, what do you do when you need to patch 1.1?  When you

When 1.1.0 is released, a 1.1.x branch is created (or it's created
later from 1.1.0 tag when needed). Once we release 1.0.0, we could
either immediately create 1.0.x branch and prepare trunk for 1.1.0
development, or we prepare trunk for 1.0.1 development and branch the
same way later as needed.

> make this 1.x branch what goes into trunk?

If there's a 1.x branch, it implies that trunk has already moved to
2.x (following the release branch pattern - the version "farthest out"
is in the trunk). The x in the branch name denotes "the trunk for all
versions of <version>.x"

Kalle

Re: Preparing for our first release

Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.

On Dec 7, 2009, at 10:27 AM, Kalle Korhonen wrote:

> On Mon, Dec 7, 2009 at 9:57 AM, Les Hazlewood  
> <lh...@apache.org> wrote:
>> A big +1 from me.
>> I've been working this way for a while now and it has been really  
>> nice thus far.
>
> Agree - this is all according to Maven and svn best practices,
> following release branching pattern (e.g.
> http://svnbook.red-bean.com/en/1.5/svn.branchmerge.commonpatterns.html) 
> .
> Though I prefer naming branches with 1.x notation (rather than 1.0 or
> 1.1) since a branch often outlives the version and Maven makes it easy
> to manage versions and branches. I'll see to it this happens. We can
> move to 1.0.0-SNAPSHOT rather quickly, then we'll deal with the
> remaining issues in the next few weeks and during the holidays, I can
> go over the poms to see that we are ready to release.

If one uses a branch name branches/1.x and let's say that 1.0, 1.1,  
and 1.2 have been released, what do you do when you need to patch  
1.1?  When you make this 1.x branch what goes into trunk?


Regards,
Alan

Re: Preparing for our first release

Posted by Les Hazlewood <lh...@apache.org>.

Beautiful!  A step-by-step guide for performing an Apache release,
complete with shell interaction.  This is what I've been wondering
about for some time.  Thanks Craig!

On Mon, Dec 7, 2009 at 4:31 PM, Craig L Russell <Cr...@sun.com> wrote:
> On this note, you might find the release branch policy used by OpenJPA
> interesting:
>
> http://openjpa.apache.org/release-management.html
> http://openjpa.apache.org/openjpa-release-policy.html
> http://openjpa.apache.org/new-release-instructions-beta.html
>
> No need to reinvent the wheel.
>
> Craig
>
> On Dec 7, 2009, at 11:49 AM, Les Hazlewood wrote:
>
>> Nice - I do this too and I agree with you Kalle that it probably more
>> naturally reflects the longevity of the branch:
>>
>> +1 to doing this for our releases.
>>
>> But where do release candidates fall in to this convention?
>>
>> - Les
>>
>> On Mon, Dec 7, 2009 at 1:27 PM, Kalle Korhonen
>> <ka...@gmail.com> wrote:
>>>
>>> On Mon, Dec 7, 2009 at 9:57 AM, Les Hazlewood <lh...@apache.org>
>>> wrote:
>>>>
>>>> A big +1 from me.
>>>> I've been working this way for a while now and it has been really nice
>>>> thus far.
>>>
>>> Agree - this is all according to Maven and svn best practices,
>>> following release branching pattern (e.g.
>>> http://svnbook.red-bean.com/en/1.5/svn.branchmerge.commonpatterns.html).
>>> Though I prefer naming branches with 1.x notation (rather than 1.0 or
>>> 1.1) since a branch often outlives the version and Maven makes it easy
>>> to manage versions and branches. I'll see to it this happens. We can
>>> move to 1.0.0-SNAPSHOT rather quickly, then we'll deal with the
>>> remaining issues in the next few weeks and during the holidays, I can
>>> go over the poms to see that we are ready to release.
>>>
>>> Kalle
>>>
>>>
>>>> On Mon, Dec 7, 2009 at 12:46 PM, Kalle Korhonen
>>>> <ka...@gmail.com> 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 <lh...@apache.org>
>>>>> 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
>>>>>>
>>>>>
>>>>
>>>
>
> Craig L Russell
> Architect, Sun Java Enterprise System http://db.apache.org/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
>

Re: Preparing for our first release

Posted by Kalle Korhonen <ka...@gmail.com>.

Yes - that's exactly what I'm saying - follow the accepted conventions
as they do. It's still useful to talk about release candidates though
since there isn't a single accepted policy at all, or whether to use
release branching pattern at all (but I've always found feature
branches having even less conventions - mostly it's free for all, so
let's not go there)

Kalle


On Mon, Dec 7, 2009 at 1:31 PM, Craig L Russell <Cr...@sun.com> wrote:
> On this note, you might find the release branch policy used by OpenJPA
> interesting:
>
> http://openjpa.apache.org/release-management.html
> http://openjpa.apache.org/openjpa-release-policy.html
> http://openjpa.apache.org/new-release-instructions-beta.html
>
> No need to reinvent the wheel.
>
> Craig
>
> On Dec 7, 2009, at 11:49 AM, Les Hazlewood wrote:
>
>> Nice - I do this too and I agree with you Kalle that it probably more
>> naturally reflects the longevity of the branch:
>>
>> +1 to doing this for our releases.
>>
>> But where do release candidates fall in to this convention?
>>
>> - Les
>>
>> On Mon, Dec 7, 2009 at 1:27 PM, Kalle Korhonen
>> <ka...@gmail.com> wrote:
>>>
>>> On Mon, Dec 7, 2009 at 9:57 AM, Les Hazlewood <lh...@apache.org>
>>> wrote:
>>>>
>>>> A big +1 from me.
>>>> I've been working this way for a while now and it has been really nice
>>>> thus far.
>>>
>>> Agree - this is all according to Maven and svn best practices,
>>> following release branching pattern (e.g.
>>> http://svnbook.red-bean.com/en/1.5/svn.branchmerge.commonpatterns.html).
>>> Though I prefer naming branches with 1.x notation (rather than 1.0 or
>>> 1.1) since a branch often outlives the version and Maven makes it easy
>>> to manage versions and branches. I'll see to it this happens. We can
>>> move to 1.0.0-SNAPSHOT rather quickly, then we'll deal with the
>>> remaining issues in the next few weeks and during the holidays, I can
>>> go over the poms to see that we are ready to release.
>>>
>>> Kalle
>>>
>>>
>>>> On Mon, Dec 7, 2009 at 12:46 PM, Kalle Korhonen
>>>> <ka...@gmail.com> 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 <lh...@apache.org>
>>>>> 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
>>>>>>
>>>>>
>>>>
>>>
>
> Craig L Russell
> Architect, Sun Java Enterprise System http://db.apache.org/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
>

Re: Preparing for our first release

Posted by Craig L Russell <Cr...@Sun.COM>.

On this note, you might find the release branch policy used by OpenJPA  
interesting:

http://openjpa.apache.org/release-management.html
http://openjpa.apache.org/openjpa-release-policy.html
http://openjpa.apache.org/new-release-instructions-beta.html

No need to reinvent the wheel.

Craig

On Dec 7, 2009, at 11:49 AM, Les Hazlewood wrote:

> Nice - I do this too and I agree with you Kalle that it probably more
> naturally reflects the longevity of the branch:
>
> +1 to doing this for our releases.
>
> But where do release candidates fall in to this convention?
>
> - Les
>
> On Mon, Dec 7, 2009 at 1:27 PM, Kalle Korhonen
> <ka...@gmail.com> wrote:
>> On Mon, Dec 7, 2009 at 9:57 AM, Les Hazlewood  
>> <lh...@apache.org> wrote:
>>> A big +1 from me.
>>> I've been working this way for a while now and it has been really  
>>> nice thus far.
>>
>> Agree - this is all according to Maven and svn best practices,
>> following release branching pattern (e.g.
>> http://svnbook.red-bean.com/en/1.5/svn.branchmerge.commonpatterns.html) 
>> .
>> Though I prefer naming branches with 1.x notation (rather than 1.0 or
>> 1.1) since a branch often outlives the version and Maven makes it  
>> easy
>> to manage versions and branches. I'll see to it this happens. We can
>> move to 1.0.0-SNAPSHOT rather quickly, then we'll deal with the
>> remaining issues in the next few weeks and during the holidays, I can
>> go over the poms to see that we are ready to release.
>>
>> Kalle
>>
>>
>>> On Mon, Dec 7, 2009 at 12:46 PM, Kalle Korhonen
>>> <ka...@gmail.com> 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 <lhazlewood@apache.org 
>>>> > 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
>>>>>
>>>>
>>>
>>

Craig L Russell
Architect, Sun Java Enterprise System http://db.apache.org/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!

Re: Preparing for our first release

Posted by Les Hazlewood <lh...@apache.org>.

Nice - I do this too and I agree with you Kalle that it probably more
naturally reflects the longevity of the branch:

+1 to doing this for our releases.

But where do release candidates fall in to this convention?

- Les

On Mon, Dec 7, 2009 at 1:27 PM, Kalle Korhonen
<ka...@gmail.com> wrote:
> On Mon, Dec 7, 2009 at 9:57 AM, Les Hazlewood <lh...@apache.org> wrote:
>> A big +1 from me.
>> I've been working this way for a while now and it has been really nice thus far.
>
> Agree - this is all according to Maven and svn best practices,
> following release branching pattern (e.g.
> http://svnbook.red-bean.com/en/1.5/svn.branchmerge.commonpatterns.html).
> Though I prefer naming branches with 1.x notation (rather than 1.0 or
> 1.1) since a branch often outlives the version and Maven makes it easy
> to manage versions and branches. I'll see to it this happens. We can
> move to 1.0.0-SNAPSHOT rather quickly, then we'll deal with the
> remaining issues in the next few weeks and during the holidays, I can
> go over the poms to see that we are ready to release.
>
> Kalle
>
>
>> On Mon, Dec 7, 2009 at 12:46 PM, Kalle Korhonen
>> <ka...@gmail.com> 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 <lh...@apache.org> 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
>>>>
>>>
>>
>

Re: Preparing for our first release

Posted by Kalle Korhonen <ka...@gmail.com>.

On Mon, Dec 7, 2009 at 9:57 AM, Les Hazlewood <lh...@apache.org> wrote:
> A big +1 from me.
> I've been working this way for a while now and it has been really nice thus far.

Agree - this is all according to Maven and svn best practices,
following release branching pattern (e.g.
http://svnbook.red-bean.com/en/1.5/svn.branchmerge.commonpatterns.html).
Though I prefer naming branches with 1.x notation (rather than 1.0 or
1.1) since a branch often outlives the version and Maven makes it easy
to manage versions and branches. I'll see to it this happens. We can
move to 1.0.0-SNAPSHOT rather quickly, then we'll deal with the
remaining issues in the next few weeks and during the holidays, I can
go over the poms to see that we are ready to release.

Kalle


> On Mon, Dec 7, 2009 at 12:46 PM, Kalle Korhonen
> <ka...@gmail.com> 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 <lh...@apache.org> 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
>>>
>>
>

Re: Preparing for our first release

Posted by Les Hazlewood <lh...@apache.org>.

A big +1 from me.

I've been working this way for a while now and it has been really nice thus far.

- Les

On Mon, Dec 7, 2009 at 12:46 PM, Kalle Korhonen
<ka...@gmail.com> 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 <lh...@apache.org> 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
>>
>

Re: Preparing for our first release

Posted by Les Hazlewood <lh...@apache.org>.

This is a great motivator ;)  Thanks Tauren!

- Les

On Mon, Dec 7, 2009 at 3:39 PM, Tauren Mills <ta...@groovee.com> wrote:
>>
>> process. Given that we've had a long and large exposure to
>
> 1.0-SNAPSHOTs (I'd assume many Shiro users are using the snapshots),
>
> I'd be inclined to keep it simple and start with blind releases and
>
>
> Not sure it matters, but I do want to note that I'm using 1.0-snapshots in
> production right now. I would guess that I'm not alone out there. For the
> most part it has been stable with only a few incidents where shiro updates
> caused a problem in my app. I would love to see a release based on something
> close to the current trunk to remove this instability.
>
> Also, the wicket-shiro project at wicketstuff can't be released until Shiro
> is in a maven repository. It has been commented out of the wicketstuff pom
> until a maven release is made, so I don't think many wicket devs are even
> aware of it or using it.  Once a release is made, I will be able to finally
> release the wicket-shiro plugin to other wicket developers.  I hope this
> will help increase awareness of the shiro project.
>
> Tauren
>

Re: Preparing for our first release

Posted by Tauren Mills <ta...@groovee.com>.

>
> process. Given that we've had a long and large exposure to

1.0-SNAPSHOTs (I'd assume many Shiro users are using the snapshots),

I'd be inclined to keep it simple and start with blind releases and


Not sure it matters, but I do want to note that I'm using 1.0-snapshots in
production right now. I would guess that I'm not alone out there. For the
most part it has been stable with only a few incidents where shiro updates
caused a problem in my app. I would love to see a release based on something
close to the current trunk to remove this instability.

Also, the wicket-shiro project at wicketstuff can't be released until Shiro
is in a maven repository. It has been commented out of the wicketstuff pom
until a maven release is made, so I don't think many wicket devs are even
aware of it or using it.  Once a release is made, I will be able to finally
release the wicket-shiro plugin to other wicket developers.  I hope this
will help increase awareness of the shiro project.

Tauren

Re: Preparing for our first release

Posted by Kalle Korhonen <ka...@gmail.com>.

On Mon, Dec 7, 2009 at 10:00 AM, Les Hazlewood <lh...@apache.org> wrote:
> Another question:
> Should we focus on one or two release candidates first?
> That is, 1.0-RC1 < 1.0-RC2 < 1.0.0 (a final release)

There are a few strategies regarding this that are currently in use at
Apache. The simplest is doing blind releases without RCs, then simply
communicating major issues and abandoning the releases if issues were
found during ro right after the release. RC is a like blind release
but the version already communicating that it is not fully tested. The
latest Maven way is doing staged releases - that is, the release is
done as normal but deployed to a staging repository (Nexus can serve
as one). You can then advertise the staging repo to a subset of users,
and if everything looks good, the staged release can be promoted to a
public release (without re-building binaries). Tapestry is attempting
to do staged releases for the first time for their next release. Maven
(the project) itself is doing both RCs and staged releases (of RCs).
As far as I know, not too many other Apache projects uses staged
releases yet, so we could wait on that and learn from others.

The right solution depends on the complexity of the codebase and how
much confidence you have on your test suite coverage and release
process. Given that we've had a long and large exposure to
1.0-SNAPSHOTs (I'd assume many Shiro users are using the snapshots),
I'd be inclined to keep it simple and start with blind releases and
see how it goes. We can always improve the process later. If 1.0.0
goes bad for some reason, we can follow-up with 1.0.1 from the branch
immediately. Just my thoughts on the topic - I'm not strongly in favor
or against any approach.

Kalle

> On Mon, Dec 7, 2009 at 12:46 PM, Kalle Korhonen
> <ka...@gmail.com> 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 <lh...@apache.org> 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
>>>
>>
>

Re: Preparing for our first release

Posted by Les Hazlewood <lh...@apache.org>.

Another question:

Should we focus on one or two release candidates first?

That is, 1.0-RC1 < 1.0-RC2 < 1.0.0 (a final release)

Thoughts?  Mentors - what have you seen in other Incubator/Graduated
projects that works well?

- Les

On Mon, Dec 7, 2009 at 12:46 PM, Kalle Korhonen
<ka...@gmail.com> 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 <lh...@apache.org> 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
>>
>

Re: Preparing for our first release

Posted by Kalle Korhonen <ka...@gmail.com>.

On Thu, May 20, 2010 at 6:17 PM, Les Hazlewood <lh...@apache.org> wrote:
> Thanks for clarifying Craig.
> Is it common for this artifact to be auto-created during the build
> process?  Or do people simply do an SVN checkout and create a .zip
> manually?

Absolutely it's common. I think the whole remote-resources plugin was
created for that purpose.

> Kalle, what do you guys do on Tapestry and/or Tynamo?

Tapestry follows the standard Apache/Maven release process and at
Tynamo, we are lucky enough to do whatever we want :) Replying
out-of-order now, but Brian is right - except that we cannot drop the
-incubating from the version - it's dictated by the incubator rules
(there was an earlier thread on that).

Kalle


> On Thu, May 20, 2010 at 5:57 PM, Craig L Russell
> <cr...@oracle.com> wrote:
>> Hi Les,
>>
>> Official release artifacts are the sources to the shiro project. The maven
>> artifacts are considered optional binary releases.
>>
>> The contents of http://svn.apache.org/repos/asf/incubator/shiro/trunk/ which
>> contains the LICENSE and NOTICE should be tar/zipped and optionally jarred.
>> Then each of the tar/jar files should be checksummed and signed with a
>> signing key using pgp, making sure the signing key is in the KEYS file.
>>
>> You should put the release artifacts somewhere that folks can evaluate them,
>> like in a user directory on people visible via the web, e.g.
>> people.apache.org/~kaosko/shiro-001.
>>
>> Craig
>>
>> On May 20, 2010, at 3:38 PM, Les Hazlewood wrote:
>>
>>> Awesome!
>>>
>>> But I just thought of a question:  what is/are our official release
>>> artifact(s)?  Most people would expect a .zip so they can download
>>> instead of being forced to use Maven, right?  We used to have a
>>> jsecurity .zip and a jsecurity-with-dependencies.zip previously.  What
>>> is good practice here in the ASF/Incubator?
>>>
>>> As I understand it, we need to distribute things like the LICENSE,
>>> README, NOTICE files and other things as well - not just the .jar/
>>> source .jar/JavaDoc .jars, right?  Our build doesn't currently make
>>> these things, so I'm just trying to understand what is conventional
>>> ASF practice.
>>>
>>> - Les
>>>
>>> On Thu, May 20, 2010 at 3:27 PM, Kalle Korhonen
>>> <ka...@gmail.com> wrote:
>>>>
>>>> Here's the new 1.0.0-incubating staging url:
>>>> https://repository.apache.org/content/repositories/orgapacheshiro-004/
>>>>
>>>> Kalle
>>>>
>>>>
>>>> On Thu, May 20, 2010 at 1:46 PM, Les Hazlewood <lh...@apache.org>
>>>> wrote:
>>>>>
>>>>> Ok, Kalle - issue has been committed to both trunk and the branch.
>>>>> Tossing the ball back in to your court...
>>>>>
>>>>> On Thu, May 20, 2010 at 1:05 PM, Les Hazlewood <lh...@apache.org>
>>>>> wrote:
>>>>>>
>>>>>> I'm running the new unit test now - fix looks good.  I'll commit in a
>>>>>> minute and re-post when I've merged into the branch.
>>>>>>
>>>>>> On Thu, May 20, 2010 at 12:18 PM, Kalle Korhonen
>>>>>> <ka...@gmail.com> wrote:
>>>>>>>
>>>>>>> Pushed the cart back to the top of the hill.
>>>>>>>
>>>>>>> Kalle
>>>>>>>
>>>>>>>
>>>>>>> On Thu, May 20, 2010 at 12:11 PM, Les Hazlewood <le...@hazlewood.com>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> No worries - merging is uber easy in Idea ;)  Thanks for doing the
>>>>>>>> rollback!
>>>>>>>>
>>>>>>>> On Thu, May 20, 2010 at 12:06 PM, Kalle Korhonen
>>>>>>>> <ka...@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>> On Thu, May 20, 2010 at 12:00 PM, Les Hazlewood
>>>>>>>>> <lh...@apache.org> wrote:
>>>>>>>>>>
>>>>>>>>>> Yeah, I can fix it rather quickly I think.  Can you do the rollback
>>>>>>>>>> while I fix it and write the test case? Also, I'm assuming I can
>>>>>>>>>> add
>>>>>>>>>> the fix to trunk?
>>>>>>>>>
>>>>>>>>> Yeah, I'll rollback and drop the staged release. You can fix it in
>>>>>>>>> the
>>>>>>>>> trunk, but the fix needs to be merged to the shiro-root-0.0.x branch
>>>>>>>>> (hey you asked for it :)
>>>>>>>>>
>>>>>>>>> Kalle
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> On Thu, May 20, 2010 at 11:47 AM, Kalle Korhonen
>>>>>>>>>> <ka...@gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>> 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
>>>>>>>>>>> <lh...@apache.org> 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
>>>>>>>>>>>> <ka...@gmail.com> 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
>>>>>>>>>>>>> <ka...@gmail.com> 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
>>>>>>>>>>>>>> <lh...@apache.org> 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
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>
>> Craig L Russell
>> Architect, Oracle
>> http://db.apache.org/jdo
>> 408 276-5638 mailto:Craig.Russell@oracle.com
>> P.S. A good JDO? O, Gasp!
>>
>>
>

Re: Preparing for our first release

Posted by Brian Demers <br...@gmail.com>.

Found it, its in the ASF parent:
http://svn.apache.org/repos/asf/maven/pom/tags/apache-7/pom.xml

So it should just work.  The LICENSE, NOTICE, etc, are packed in the
META-INF, in the sources bundle (per module):
https://repository.apache.org/service/local/repositories/orgapacheshiro-004/archive/org/apache/shiro/shiro-core/1.0.0-incubating/shiro-core-1.0.0-incubating-sources.jar/!/META-INF/LICENSE

NOTE: the shiro-all, sources doesn't have any source, it just contains the
LICENSE, etc

On a side note, can we get the "incubating" dropped from the version?   This
might confuse people, as Shiro well deserves a clean 1.0.0 stamp!


On Thu, May 20, 2010 at 10:08 PM, Brian Demers <br...@gmail.com>wrote:

>
> There were changes not to long ago so that maven would bundle an ASF
> friendly bundle (as maven itself has the same requirements)
> I'll see if i can dig it up.
>
>
> On Thu, May 20, 2010 at 9:24 PM, Gavin Hogan <GH...@commercehub.com>wrote:
>
>> Hey Les
>>
>> I thought maven does this pretty well via assembly -
>> http://maven.apache.org/plugins/maven-assembly-plugin/
>>
>> Have never had reason to use this, just thought I would point it out.
>>
>> Good luck with the release....
>>
>> Gavin
>>
>>
>>
>> From:
>> Les Hazlewood <lh...@apache.org>
>> To:
>> shiro-dev@incubator.apache.org
>> Date:
>> 05/20/2010 09:20 PM
>> Subject:
>> [SPAM] - Re: Preparing for our first release - Bayesian Filter detected
>> spam
>>
>>
>>
>> Thanks for clarifying Craig.
>>
>> Is it common for this artifact to be auto-created during the build
>> process?  Or do people simply do an SVN checkout and create a .zip
>> manually?
>>
>> Kalle, what do you guys do on Tapestry and/or Tynamo?
>>
>> On Thu, May 20, 2010 at 5:57 PM, Craig L Russell
>> <cr...@oracle.com> wrote:
>> > Hi Les,
>> >
>> > Official release artifacts are the sources to the shiro project. The
>> maven
>> > artifacts are considered optional binary releases.
>> >
>> > The contents of http://svn.apache.org/repos/asf/incubator/shiro/trunk/
>> which
>> > contains the LICENSE and NOTICE should be tar/zipped and optionally
>> jarred.
>> > Then each of the tar/jar files should be checksummed and signed with a
>> > signing key using pgp, making sure the signing key is in the KEYS file.
>> >
>> > You should put the release artifacts somewhere that folks can evaluate
>> them,
>> > like in a user directory on people visible via the web, e.g.
>> > people.apache.org/~kaosko/shiro-001.
>> >
>> > Craig
>> >
>> > On May 20, 2010, at 3:38 PM, Les Hazlewood wrote:
>> >
>> >> Awesome!
>> >>
>> >> But I just thought of a question:  what is/are our official release
>> >> artifact(s)?  Most people would expect a .zip so they can download
>> >> instead of being forced to use Maven, right?  We used to have a
>> >> jsecurity .zip and a jsecurity-with-dependencies.zip previously.  What
>> >> is good practice here in the ASF/Incubator?
>> >>
>> >> As I understand it, we need to distribute things like the LICENSE,
>> >> README, NOTICE files and other things as well - not just the .jar/
>> >> source .jar/JavaDoc .jars, right?  Our build doesn't currently make
>> >> these things, so I'm just trying to understand what is conventional
>> >> ASF practice.
>> >>
>> >> - Les
>> >>
>> >> On Thu, May 20, 2010 at 3:27 PM, Kalle Korhonen
>> >> <ka...@gmail.com> wrote:
>> >>>
>> >>> Here's the new 1.0.0-incubating staging url:
>> >>>
>> https://repository.apache.org/content/repositories/orgapacheshiro-004/
>> >>>
>> >>> Kalle
>> >>>
>> >>>
>> >>> On Thu, May 20, 2010 at 1:46 PM, Les Hazlewood <lhazlewood@apache.org
>> >
>> >>> wrote:
>> >>>>
>> >>>> Ok, Kalle - issue has been committed to both trunk and the branch.
>> >>>> Tossing the ball back in to your court...
>> >>>>
>> >>>> On Thu, May 20, 2010 at 1:05 PM, Les Hazlewood
>> <lh...@apache.org>
>> >>>> wrote:
>> >>>>>
>> >>>>> I'm running the new unit test now - fix looks good.  I'll commit in
>> a
>> >>>>> minute and re-post when I've merged into the branch.
>> >>>>>
>> >>>>> On Thu, May 20, 2010 at 12:18 PM, Kalle Korhonen
>> >>>>> <ka...@gmail.com> wrote:
>> >>>>>>
>> >>>>>> Pushed the cart back to the top of the hill.
>> >>>>>>
>> >>>>>> Kalle
>> >>>>>>
>> >>>>>>
>> >>>>>> On Thu, May 20, 2010 at 12:11 PM, Les Hazlewood <les@hazlewood.com
>> >
>> >>>>>> wrote:
>> >>>>>>>
>> >>>>>>> No worries - merging is uber easy in Idea ;)  Thanks for doing the
>> >>>>>>> rollback!
>> >>>>>>>
>> >>>>>>> On Thu, May 20, 2010 at 12:06 PM, Kalle Korhonen
>> >>>>>>> <ka...@gmail.com> wrote:
>> >>>>>>>>
>> >>>>>>>> On Thu, May 20, 2010 at 12:00 PM, Les Hazlewood
>> >>>>>>>> <lh...@apache.org> wrote:
>> >>>>>>>>>
>> >>>>>>>>> Yeah, I can fix it rather quickly I think.  Can you do the
>> rollback
>> >>>>>>>>> while I fix it and write the test case? Also, I'm assuming I can
>> >>>>>>>>> add
>> >>>>>>>>> the fix to trunk?
>> >>>>>>>>
>> >>>>>>>> Yeah, I'll rollback and drop the staged release. You can fix it
>> in
>> >>>>>>>> the
>> >>>>>>>> trunk, but the fix needs to be merged to the shiro-root-0.0.x
>> branch
>> >>>>>>>> (hey you asked for it :)
>> >>>>>>>>
>> >>>>>>>> Kalle
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>> On Thu, May 20, 2010 at 11:47 AM, Kalle Korhonen
>> >>>>>>>>> <ka...@gmail.com> wrote:
>> >>>>>>>>>>
>> >>>>>>>>>> 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
>> >>>>>>>>>> <lh...@apache.org> 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
>> >>>>>>>>>>> <ka...@gmail.com> 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
>> >>>>>>>>>>>> <ka...@gmail.com> 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
>> >>>>>>>>>>>>> <lh...@apache.org> 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
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>
>> >>>>>>>
>> >>>>>>
>> >>>>>
>> >>>>
>> >>>
>> >
>> > Craig L Russell
>> > Architect, Oracle
>> > http://db.apache.org/jdo
>> > 408 276-5638 mailto:Craig.Russell@oracle.com
>> > P.S. A good JDO? O, Gasp!
>> >
>> >
>>
>>
>>
>

Re: Preparing for our first release

Posted by Brian Demers <br...@gmail.com>.

There were changes not to long ago so that maven would bundle an ASF
friendly bundle (as maven itself has the same requirements)
I'll see if i can dig it up.


On Thu, May 20, 2010 at 9:24 PM, Gavin Hogan <GH...@commercehub.com> wrote:

> Hey Les
>
> I thought maven does this pretty well via assembly -
> http://maven.apache.org/plugins/maven-assembly-plugin/
>
> Have never had reason to use this, just thought I would point it out.
>
> Good luck with the release....
>
> Gavin
>
>
>
> From:
> Les Hazlewood <lh...@apache.org>
> To:
> shiro-dev@incubator.apache.org
> Date:
> 05/20/2010 09:20 PM
> Subject:
> [SPAM] - Re: Preparing for our first release - Bayesian Filter detected
> spam
>
>
>
> Thanks for clarifying Craig.
>
> Is it common for this artifact to be auto-created during the build
> process?  Or do people simply do an SVN checkout and create a .zip
> manually?
>
> Kalle, what do you guys do on Tapestry and/or Tynamo?
>
> On Thu, May 20, 2010 at 5:57 PM, Craig L Russell
> <cr...@oracle.com> wrote:
> > Hi Les,
> >
> > Official release artifacts are the sources to the shiro project. The
> maven
> > artifacts are considered optional binary releases.
> >
> > The contents of http://svn.apache.org/repos/asf/incubator/shiro/trunk/
> which
> > contains the LICENSE and NOTICE should be tar/zipped and optionally
> jarred.
> > Then each of the tar/jar files should be checksummed and signed with a
> > signing key using pgp, making sure the signing key is in the KEYS file.
> >
> > You should put the release artifacts somewhere that folks can evaluate
> them,
> > like in a user directory on people visible via the web, e.g.
> > people.apache.org/~kaosko/shiro-001.
> >
> > Craig
> >
> > On May 20, 2010, at 3:38 PM, Les Hazlewood wrote:
> >
> >> Awesome!
> >>
> >> But I just thought of a question:  what is/are our official release
> >> artifact(s)?  Most people would expect a .zip so they can download
> >> instead of being forced to use Maven, right?  We used to have a
> >> jsecurity .zip and a jsecurity-with-dependencies.zip previously.  What
> >> is good practice here in the ASF/Incubator?
> >>
> >> As I understand it, we need to distribute things like the LICENSE,
> >> README, NOTICE files and other things as well - not just the .jar/
> >> source .jar/JavaDoc .jars, right?  Our build doesn't currently make
> >> these things, so I'm just trying to understand what is conventional
> >> ASF practice.
> >>
> >> - Les
> >>
> >> On Thu, May 20, 2010 at 3:27 PM, Kalle Korhonen
> >> <ka...@gmail.com> wrote:
> >>>
> >>> Here's the new 1.0.0-incubating staging url:
> >>> https://repository.apache.org/content/repositories/orgapacheshiro-004/
> >>>
> >>> Kalle
> >>>
> >>>
> >>> On Thu, May 20, 2010 at 1:46 PM, Les Hazlewood <lh...@apache.org>
> >>> wrote:
> >>>>
> >>>> Ok, Kalle - issue has been committed to both trunk and the branch.
> >>>> Tossing the ball back in to your court...
> >>>>
> >>>> On Thu, May 20, 2010 at 1:05 PM, Les Hazlewood
> <lh...@apache.org>
> >>>> wrote:
> >>>>>
> >>>>> I'm running the new unit test now - fix looks good.  I'll commit in
> a
> >>>>> minute and re-post when I've merged into the branch.
> >>>>>
> >>>>> On Thu, May 20, 2010 at 12:18 PM, Kalle Korhonen
> >>>>> <ka...@gmail.com> wrote:
> >>>>>>
> >>>>>> Pushed the cart back to the top of the hill.
> >>>>>>
> >>>>>> Kalle
> >>>>>>
> >>>>>>
> >>>>>> On Thu, May 20, 2010 at 12:11 PM, Les Hazlewood <le...@hazlewood.com>
> >>>>>> wrote:
> >>>>>>>
> >>>>>>> No worries - merging is uber easy in Idea ;)  Thanks for doing the
> >>>>>>> rollback!
> >>>>>>>
> >>>>>>> On Thu, May 20, 2010 at 12:06 PM, Kalle Korhonen
> >>>>>>> <ka...@gmail.com> wrote:
> >>>>>>>>
> >>>>>>>> On Thu, May 20, 2010 at 12:00 PM, Les Hazlewood
> >>>>>>>> <lh...@apache.org> wrote:
> >>>>>>>>>
> >>>>>>>>> Yeah, I can fix it rather quickly I think.  Can you do the
> rollback
> >>>>>>>>> while I fix it and write the test case? Also, I'm assuming I can
> >>>>>>>>> add
> >>>>>>>>> the fix to trunk?
> >>>>>>>>
> >>>>>>>> Yeah, I'll rollback and drop the staged release. You can fix it
> in
> >>>>>>>> the
> >>>>>>>> trunk, but the fix needs to be merged to the shiro-root-0.0.x
> branch
> >>>>>>>> (hey you asked for it :)
> >>>>>>>>
> >>>>>>>> Kalle
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> On Thu, May 20, 2010 at 11:47 AM, Kalle Korhonen
> >>>>>>>>> <ka...@gmail.com> wrote:
> >>>>>>>>>>
> >>>>>>>>>> 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
> >>>>>>>>>> <lh...@apache.org> 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
> >>>>>>>>>>> <ka...@gmail.com> 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
> >>>>>>>>>>>> <ka...@gmail.com> 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
> >>>>>>>>>>>>> <lh...@apache.org> 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
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >
> > Craig L Russell
> > Architect, Oracle
> > http://db.apache.org/jdo
> > 408 276-5638 mailto:Craig.Russell@oracle.com
> > P.S. A good JDO? O, Gasp!
> >
> >
>
>
>

Re: Preparing for our first release

Posted by Gavin Hogan <GH...@commercehub.com>.

Hey Les

I thought maven does this pretty well via assembly - 
http://maven.apache.org/plugins/maven-assembly-plugin/

Have never had reason to use this, just thought I would point it out.

Good luck with the release....

Gavin



From:
Les Hazlewood <lh...@apache.org>
To:
shiro-dev@incubator.apache.org
Date:
05/20/2010 09:20 PM
Subject:
[SPAM] - Re: Preparing for our first release - Bayesian Filter detected 
spam



Thanks for clarifying Craig.

Is it common for this artifact to be auto-created during the build
process?  Or do people simply do an SVN checkout and create a .zip
manually?

Kalle, what do you guys do on Tapestry and/or Tynamo?

On Thu, May 20, 2010 at 5:57 PM, Craig L Russell
<cr...@oracle.com> wrote:
> Hi Les,
>
> Official release artifacts are the sources to the shiro project. The 
maven
> artifacts are considered optional binary releases.
>
> The contents of http://svn.apache.org/repos/asf/incubator/shiro/trunk/ 
which
> contains the LICENSE and NOTICE should be tar/zipped and optionally 
jarred.
> Then each of the tar/jar files should be checksummed and signed with a
> signing key using pgp, making sure the signing key is in the KEYS file.
>
> You should put the release artifacts somewhere that folks can evaluate 
them,
> like in a user directory on people visible via the web, e.g.
> people.apache.org/~kaosko/shiro-001.
>
> Craig
>
> On May 20, 2010, at 3:38 PM, Les Hazlewood wrote:
>
>> Awesome!
>>
>> But I just thought of a question:  what is/are our official release
>> artifact(s)?  Most people would expect a .zip so they can download
>> instead of being forced to use Maven, right?  We used to have a
>> jsecurity .zip and a jsecurity-with-dependencies.zip previously.  What
>> is good practice here in the ASF/Incubator?
>>
>> As I understand it, we need to distribute things like the LICENSE,
>> README, NOTICE files and other things as well - not just the .jar/
>> source .jar/JavaDoc .jars, right?  Our build doesn't currently make
>> these things, so I'm just trying to understand what is conventional
>> ASF practice.
>>
>> - Les
>>
>> On Thu, May 20, 2010 at 3:27 PM, Kalle Korhonen
>> <ka...@gmail.com> wrote:
>>>
>>> Here's the new 1.0.0-incubating staging url:
>>> https://repository.apache.org/content/repositories/orgapacheshiro-004/
>>>
>>> Kalle
>>>
>>>
>>> On Thu, May 20, 2010 at 1:46 PM, Les Hazlewood <lh...@apache.org>
>>> wrote:
>>>>
>>>> Ok, Kalle - issue has been committed to both trunk and the branch.
>>>> Tossing the ball back in to your court...
>>>>
>>>> On Thu, May 20, 2010 at 1:05 PM, Les Hazlewood 
<lh...@apache.org>
>>>> wrote:
>>>>>
>>>>> I'm running the new unit test now - fix looks good.  I'll commit in 
a
>>>>> minute and re-post when I've merged into the branch.
>>>>>
>>>>> On Thu, May 20, 2010 at 12:18 PM, Kalle Korhonen
>>>>> <ka...@gmail.com> wrote:
>>>>>>
>>>>>> Pushed the cart back to the top of the hill.
>>>>>>
>>>>>> Kalle
>>>>>>
>>>>>>
>>>>>> On Thu, May 20, 2010 at 12:11 PM, Les Hazlewood <le...@hazlewood.com>
>>>>>> wrote:
>>>>>>>
>>>>>>> No worries - merging is uber easy in Idea ;)  Thanks for doing the
>>>>>>> rollback!
>>>>>>>
>>>>>>> On Thu, May 20, 2010 at 12:06 PM, Kalle Korhonen
>>>>>>> <ka...@gmail.com> wrote:
>>>>>>>>
>>>>>>>> On Thu, May 20, 2010 at 12:00 PM, Les Hazlewood
>>>>>>>> <lh...@apache.org> wrote:
>>>>>>>>>
>>>>>>>>> Yeah, I can fix it rather quickly I think.  Can you do the 
rollback
>>>>>>>>> while I fix it and write the test case? Also, I'm assuming I can
>>>>>>>>> add
>>>>>>>>> the fix to trunk?
>>>>>>>>
>>>>>>>> Yeah, I'll rollback and drop the staged release. You can fix it 
in
>>>>>>>> the
>>>>>>>> trunk, but the fix needs to be merged to the shiro-root-0.0.x 
branch
>>>>>>>> (hey you asked for it :)
>>>>>>>>
>>>>>>>> Kalle
>>>>>>>>
>>>>>>>>
>>>>>>>>> On Thu, May 20, 2010 at 11:47 AM, Kalle Korhonen
>>>>>>>>> <ka...@gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>> 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
>>>>>>>>>> <lh...@apache.org> 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
>>>>>>>>>>> <ka...@gmail.com> 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
>>>>>>>>>>>> <ka...@gmail.com> 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
>>>>>>>>>>>>> <lh...@apache.org> 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
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>
> Craig L Russell
> Architect, Oracle
> http://db.apache.org/jdo
> 408 276-5638 mailto:Craig.Russell@oracle.com
> P.S. A good JDO? O, Gasp!
>
>

Re: Preparing for our first release

Posted by Les Hazlewood <lh...@apache.org>.

Thanks for clarifying Craig.

Is it common for this artifact to be auto-created during the build
process?  Or do people simply do an SVN checkout and create a .zip
manually?

Kalle, what do you guys do on Tapestry and/or Tynamo?

On Thu, May 20, 2010 at 5:57 PM, Craig L Russell
<cr...@oracle.com> wrote:
> Hi Les,
>
> Official release artifacts are the sources to the shiro project. The maven
> artifacts are considered optional binary releases.
>
> The contents of http://svn.apache.org/repos/asf/incubator/shiro/trunk/ which
> contains the LICENSE and NOTICE should be tar/zipped and optionally jarred.
> Then each of the tar/jar files should be checksummed and signed with a
> signing key using pgp, making sure the signing key is in the KEYS file.
>
> You should put the release artifacts somewhere that folks can evaluate them,
> like in a user directory on people visible via the web, e.g.
> people.apache.org/~kaosko/shiro-001.
>
> Craig
>
> On May 20, 2010, at 3:38 PM, Les Hazlewood wrote:
>
>> Awesome!
>>
>> But I just thought of a question:  what is/are our official release
>> artifact(s)?  Most people would expect a .zip so they can download
>> instead of being forced to use Maven, right?  We used to have a
>> jsecurity .zip and a jsecurity-with-dependencies.zip previously.  What
>> is good practice here in the ASF/Incubator?
>>
>> As I understand it, we need to distribute things like the LICENSE,
>> README, NOTICE files and other things as well - not just the .jar/
>> source .jar/JavaDoc .jars, right?  Our build doesn't currently make
>> these things, so I'm just trying to understand what is conventional
>> ASF practice.
>>
>> - Les
>>
>> On Thu, May 20, 2010 at 3:27 PM, Kalle Korhonen
>> <ka...@gmail.com> wrote:
>>>
>>> Here's the new 1.0.0-incubating staging url:
>>> https://repository.apache.org/content/repositories/orgapacheshiro-004/
>>>
>>> Kalle
>>>
>>>
>>> On Thu, May 20, 2010 at 1:46 PM, Les Hazlewood <lh...@apache.org>
>>> wrote:
>>>>
>>>> Ok, Kalle - issue has been committed to both trunk and the branch.
>>>> Tossing the ball back in to your court...
>>>>
>>>> On Thu, May 20, 2010 at 1:05 PM, Les Hazlewood <lh...@apache.org>
>>>> wrote:
>>>>>
>>>>> I'm running the new unit test now - fix looks good.  I'll commit in a
>>>>> minute and re-post when I've merged into the branch.
>>>>>
>>>>> On Thu, May 20, 2010 at 12:18 PM, Kalle Korhonen
>>>>> <ka...@gmail.com> wrote:
>>>>>>
>>>>>> Pushed the cart back to the top of the hill.
>>>>>>
>>>>>> Kalle
>>>>>>
>>>>>>
>>>>>> On Thu, May 20, 2010 at 12:11 PM, Les Hazlewood <le...@hazlewood.com>
>>>>>> wrote:
>>>>>>>
>>>>>>> No worries - merging is uber easy in Idea ;)  Thanks for doing the
>>>>>>> rollback!
>>>>>>>
>>>>>>> On Thu, May 20, 2010 at 12:06 PM, Kalle Korhonen
>>>>>>> <ka...@gmail.com> wrote:
>>>>>>>>
>>>>>>>> On Thu, May 20, 2010 at 12:00 PM, Les Hazlewood
>>>>>>>> <lh...@apache.org> wrote:
>>>>>>>>>
>>>>>>>>> Yeah, I can fix it rather quickly I think.  Can you do the rollback
>>>>>>>>> while I fix it and write the test case? Also, I'm assuming I can
>>>>>>>>> add
>>>>>>>>> the fix to trunk?
>>>>>>>>
>>>>>>>> Yeah, I'll rollback and drop the staged release. You can fix it in
>>>>>>>> the
>>>>>>>> trunk, but the fix needs to be merged to the shiro-root-0.0.x branch
>>>>>>>> (hey you asked for it :)
>>>>>>>>
>>>>>>>> Kalle
>>>>>>>>
>>>>>>>>
>>>>>>>>> On Thu, May 20, 2010 at 11:47 AM, Kalle Korhonen
>>>>>>>>> <ka...@gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>> 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
>>>>>>>>>> <lh...@apache.org> 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
>>>>>>>>>>> <ka...@gmail.com> 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
>>>>>>>>>>>> <ka...@gmail.com> 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
>>>>>>>>>>>>> <lh...@apache.org> 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
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>
> Craig L Russell
> Architect, Oracle
> http://db.apache.org/jdo
> 408 276-5638 mailto:Craig.Russell@oracle.com
> P.S. A good JDO? O, Gasp!
>
>

Re: Preparing for our first release

Posted by Les Hazlewood <lh...@apache.org>.

Ah

On Thu, May 20, 2010 at 11:51 PM, Brett Porter <br...@apache.org> wrote:
> On 21/05/2010, at 4:43 PM, Les Hazlewood wrote:
>
>> Mentors,
>>
>> Is there anything with an exact step-by-step guide for walking through
>> the release steps for maven-based projects?  Something like this:
>>
>> http://wiki.apache.org/hadoop/HowToRelease
>>
>> (but for Maven projects).  The Incubator Release guide is more
>> philosophical than practical: I'm looking for a 'do x, then y, then z'
>> with command line snippets to automate as much as possible.  Does
>> anyone know of anything like this?  It'd be much easier to 'just do
>> it' than try to interpret the Incubator guide.
>
> http://maven.apache.org/developers/release/apache-release.html
>
> It's not exhaustive on the requirements - I think it gets you as far as Kalle already has.
>
> As long as the source bundles were produced, then that should be fine. I think that's https://repository.apache.org/content/repositories/orgapacheshiro-004/org/apache/shiro/shiro-root/1.0.0-incubating/

Ah yes - it's late and I'm tired :/  My apologies for being dense -
thanks for opening my eyes :)

> However, I tend to agree with Craig that you should lay them out in a format like you would eventually copy into www.apache.org/dist/ as well so that it's clear.
>
> I didn't see a binary release (something for non-maven users) - is that just the shiro-all JAR?

I believe that is the intention at the moment.  We can make a little
more robust binary package for later releases, I'm sure.  I think
we're just trying to make it through this one first :)

Thanks for the pointers!

Les

Re: Preparing for our first release

Posted by Kalle Korhonen <ka...@gmail.com>.

I even tried to integrate the Maven rat plugin, 0.6, but I couldn't
get it to work because the excludes (for readmes) didn't seem to take
effect -  but nevertheless, it didn't report much issues.

Kalle


On Fri, May 21, 2010 at 7:18 AM, Alan D. Cabrera <ad...@toolazydogs.com> wrote:
>
> On May 21, 2010, at 6:50 AM, Alan D. Cabrera wrote:
>
>>
>> On May 21, 2010, at 5:59 AM, Craig L Russell wrote:
>>
>>> On May 20, 2010, at 11:51 PM, Brett Porter wrote:
>>>
>>>> On 21/05/2010, at 4:43 PM, Les Hazlewood wrote:
>>>>
>>>>> Mentors,
>>>>>
>>>>> Is there anything with an exact step-by-step guide for walking through
>>>>> the release steps for maven-based projects?  Something like this:
>>>>>
>>>>> http://wiki.apache.org/hadoop/HowToRelease
>>>>>
>>>>> (but for Maven projects).  The Incubator Release guide is more
>>>>> philosophical than practical: I'm looking for a 'do x, then y, then z'
>>>>> with command line snippets to automate as much as possible.  Does
>>>>> anyone know of anything like this?  It'd be much easier to 'just do
>>>>> it' than try to interpret the Incubator guide.
>>>>
>>>> http://maven.apache.org/developers/release/apache-release.html
>>>
>>> This page doesn't mention how to create the www.apache.org/dist/ bundles,, i.e. http://www.apache.org/dist/maven/source/
>>>
>>> What we will need as the source distribution will go into http://www.apache.org/dist/incubator/shiro
>>>
>>> So I think we're very close, but do need to make sure that the release artifacts that are voted end up both in the maven repository (binary distribution) and dist/incubator/shiro (source distribution).
>>>
>>> Great progress.
>>
>> Has someone run rat on this dist?
>
> Just did.  Looks good.
>
>
> Regards,
> Alan
>
>

Re: Preparing for our first release

Posted by "Alan D. Cabrera" <ad...@toolazydogs.com>.

On May 21, 2010, at 6:50 AM, Alan D. Cabrera wrote:

> 
> On May 21, 2010, at 5:59 AM, Craig L Russell wrote:
> 
>> On May 20, 2010, at 11:51 PM, Brett Porter wrote:
>> 
>>> On 21/05/2010, at 4:43 PM, Les Hazlewood wrote:
>>> 
>>>> Mentors,
>>>> 
>>>> Is there anything with an exact step-by-step guide for walking through
>>>> the release steps for maven-based projects?  Something like this:
>>>> 
>>>> http://wiki.apache.org/hadoop/HowToRelease
>>>> 
>>>> (but for Maven projects).  The Incubator Release guide is more
>>>> philosophical than practical: I'm looking for a 'do x, then y, then z'
>>>> with command line snippets to automate as much as possible.  Does
>>>> anyone know of anything like this?  It'd be much easier to 'just do
>>>> it' than try to interpret the Incubator guide.
>>> 
>>> http://maven.apache.org/developers/release/apache-release.html
>> 
>> This page doesn't mention how to create the www.apache.org/dist/ bundles,, i.e. http://www.apache.org/dist/maven/source/
>> 
>> What we will need as the source distribution will go into http://www.apache.org/dist/incubator/shiro
>> 
>> So I think we're very close, but do need to make sure that the release artifacts that are voted end up both in the maven repository (binary distribution) and dist/incubator/shiro (source distribution).
>> 
>> Great progress.
> 
> Has someone run rat on this dist?

Just did.  Looks good.


Regards,
Alan

Re: Preparing for our first release

Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.

On May 21, 2010, at 5:59 AM, Craig L Russell wrote:

> On May 20, 2010, at 11:51 PM, Brett Porter wrote:
> 
>> On 21/05/2010, at 4:43 PM, Les Hazlewood wrote:
>> 
>>> Mentors,
>>> 
>>> Is there anything with an exact step-by-step guide for walking through
>>> the release steps for maven-based projects?  Something like this:
>>> 
>>> http://wiki.apache.org/hadoop/HowToRelease
>>> 
>>> (but for Maven projects).  The Incubator Release guide is more
>>> philosophical than practical: I'm looking for a 'do x, then y, then z'
>>> with command line snippets to automate as much as possible.  Does
>>> anyone know of anything like this?  It'd be much easier to 'just do
>>> it' than try to interpret the Incubator guide.
>> 
>> http://maven.apache.org/developers/release/apache-release.html
> 
> This page doesn't mention how to create the www.apache.org/dist/ bundles,, i.e. http://www.apache.org/dist/maven/source/
> 
> What we will need as the source distribution will go into http://www.apache.org/dist/incubator/shiro
> 
> So I think we're very close, but do need to make sure that the release artifacts that are voted end up both in the maven repository (binary distribution) and dist/incubator/shiro (source distribution).
> 
> Great progress.

Has someone run rat on this dist?


Regards,
Alan

Re: Preparing for our first release

Posted by Craig L Russell <cr...@oracle.com>.

On May 20, 2010, at 11:51 PM, Brett Porter wrote:

> On 21/05/2010, at 4:43 PM, Les Hazlewood wrote:
>
>> Mentors,
>>
>> Is there anything with an exact step-by-step guide for walking  
>> through
>> the release steps for maven-based projects?  Something like this:
>>
>> http://wiki.apache.org/hadoop/HowToRelease
>>
>> (but for Maven projects).  The Incubator Release guide is more
>> philosophical than practical: I'm looking for a 'do x, then y, then  
>> z'
>> with command line snippets to automate as much as possible.  Does
>> anyone know of anything like this?  It'd be much easier to 'just do
>> it' than try to interpret the Incubator guide.
>
> http://maven.apache.org/developers/release/apache-release.html

This page doesn't mention how to create the www.apache.org/dist/  
bundles,, i.e. http://www.apache.org/dist/maven/source/

What we will need as the source distribution will go into http://www.apache.org/dist/incubator/shiro

So I think we're very close, but do need to make sure that the release  
artifacts that are voted end up both in the maven repository (binary  
distribution) and dist/incubator/shiro (source distribution).

Great progress.

Craig

>
> It's not exhaustive on the requirements - I think it gets you as far  
> as Kalle already has.
>
> As long as the source bundles were produced, then that should be  
> fine. I think that's https://repository.apache.org/content/repositories/orgapacheshiro-004/org/apache/shiro/shiro-root/1.0.0-incubating/
>
> However, I tend to agree with Craig that you should lay them out in  
> a format like you would eventually copy into www.apache.org/dist/ as  
> well so that it's clear.
>
> I didn't see a binary release (something for non-maven users) - is  
> that just the shiro-all JAR?
>
> Cheers,
> Brett
>
> --
> Brett Porter
> brett@apache.org
> http://brettporter.wordpress.com/
>

Craig L Russell
Architect, Oracle
http://db.apache.org/jdo
408 276-5638 mailto:Craig.Russell@oracle.com
P.S. A good JDO? O, Gasp!

Re: Preparing for our first release

Posted by Brett Porter <br...@apache.org>.

On 21/05/2010, at 4:43 PM, Les Hazlewood wrote:

> Mentors,
> 
> Is there anything with an exact step-by-step guide for walking through
> the release steps for maven-based projects?  Something like this:
> 
> http://wiki.apache.org/hadoop/HowToRelease
> 
> (but for Maven projects).  The Incubator Release guide is more
> philosophical than practical: I'm looking for a 'do x, then y, then z'
> with command line snippets to automate as much as possible.  Does
> anyone know of anything like this?  It'd be much easier to 'just do
> it' than try to interpret the Incubator guide.

http://maven.apache.org/developers/release/apache-release.html

It's not exhaustive on the requirements - I think it gets you as far as Kalle already has.

As long as the source bundles were produced, then that should be fine. I think that's https://repository.apache.org/content/repositories/orgapacheshiro-004/org/apache/shiro/shiro-root/1.0.0-incubating/

However, I tend to agree with Craig that you should lay them out in a format like you would eventually copy into www.apache.org/dist/ as well so that it's clear.

I didn't see a binary release (something for non-maven users) - is that just the shiro-all JAR?

Cheers,
Brett

--
Brett Porter
brett@apache.org
http://brettporter.wordpress.com/

Re: Preparing for our first release

Posted by Les Hazlewood <lh...@apache.org>.

Mentors,

Is there anything with an exact step-by-step guide for walking through
the release steps for maven-based projects?  Something like this:

http://wiki.apache.org/hadoop/HowToRelease

(but for Maven projects).  The Incubator Release guide is more
philosophical than practical: I'm looking for a 'do x, then y, then z'
with command line snippets to automate as much as possible.  Does
anyone know of anything like this?  It'd be much easier to 'just do
it' than try to interpret the Incubator guide.

- Les

On Thu, May 20, 2010 at 11:02 PM, Craig L Russell
<cr...@oracle.com> wrote:
>
> On May 20, 2010, at 7:32 PM, Kalle Korhonen wrote:
>
>> On Thu, May 20, 2010 at 5:57 PM, Craig L Russell
>> <cr...@oracle.com> wrote:
>>>
>>> You should put the release artifacts somewhere that folks can evaluate
>>> them,
>>> like in a user directory on people visible via the web, e.g.
>>> people.apache.org/~kaosko/shiro-001.
>>
>> That's exactly what the staging repository is for.
>
> Except that I didn't see anything in the staging repo that looks like a
> gzip/jar with checksums and signatures. Maybe you can point it out to me.
>
> Thanks,
>
> Craig
>>
>> Kalle
>>
>>
>>> On May 20, 2010, at 3:38 PM, Les Hazlewood wrote:
>>>
>>>> Awesome!
>>>>
>>>> But I just thought of a question:  what is/are our official release
>>>> artifact(s)?  Most people would expect a .zip so they can download
>>>> instead of being forced to use Maven, right?  We used to have a
>>>> jsecurity .zip and a jsecurity-with-dependencies.zip previously.  What
>>>> is good practice here in the ASF/Incubator?
>>>>
>>>> As I understand it, we need to distribute things like the LICENSE,
>>>> README, NOTICE files and other things as well - not just the .jar/
>>>> source .jar/JavaDoc .jars, right?  Our build doesn't currently make
>>>> these things, so I'm just trying to understand what is conventional
>>>> ASF practice.
>>>>
>>>> - Les
>>>>
>>>> On Thu, May 20, 2010 at 3:27 PM, Kalle Korhonen
>>>> <ka...@gmail.com> wrote:
>>>>>
>>>>> Here's the new 1.0.0-incubating staging url:
>>>>> https://repository.apache.org/content/repositories/orgapacheshiro-004/
>>>>>
>>>>> Kalle
>>>>>
>>>>>
>>>>> On Thu, May 20, 2010 at 1:46 PM, Les Hazlewood <lh...@apache.org>
>>>>> wrote:
>>>>>>
>>>>>> Ok, Kalle - issue has been committed to both trunk and the branch.
>>>>>> Tossing the ball back in to your court...
>>>>>>
>>>>>> On Thu, May 20, 2010 at 1:05 PM, Les Hazlewood <lh...@apache.org>
>>>>>> wrote:
>>>>>>>
>>>>>>> I'm running the new unit test now - fix looks good.  I'll commit in a
>>>>>>> minute and re-post when I've merged into the branch.
>>>>>>>
>>>>>>> On Thu, May 20, 2010 at 12:18 PM, Kalle Korhonen
>>>>>>> <ka...@gmail.com> wrote:
>>>>>>>>
>>>>>>>> Pushed the cart back to the top of the hill.
>>>>>>>>
>>>>>>>> Kalle
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, May 20, 2010 at 12:11 PM, Les Hazlewood <le...@hazlewood.com>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> No worries - merging is uber easy in Idea ;)  Thanks for doing the
>>>>>>>>> rollback!
>>>>>>>>>
>>>>>>>>> On Thu, May 20, 2010 at 12:06 PM, Kalle Korhonen
>>>>>>>>> <ka...@gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>> On Thu, May 20, 2010 at 12:00 PM, Les Hazlewood
>>>>>>>>>> <lh...@apache.org> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Yeah, I can fix it rather quickly I think.  Can you do the
>>>>>>>>>>> rollback
>>>>>>>>>>> while I fix it and write the test case? Also, I'm assuming I can
>>>>>>>>>>> add
>>>>>>>>>>> the fix to trunk?
>>>>>>>>>>
>>>>>>>>>> Yeah, I'll rollback and drop the staged release. You can fix it in
>>>>>>>>>> the
>>>>>>>>>> trunk, but the fix needs to be merged to the shiro-root-0.0.x
>>>>>>>>>> branch
>>>>>>>>>> (hey you asked for it :)
>>>>>>>>>>
>>>>>>>>>> Kalle
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> On Thu, May 20, 2010 at 11:47 AM, Kalle Korhonen
>>>>>>>>>>> <ka...@gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> 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
>>>>>>>>>>>> <lh...@apache.org> 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
>>>>>>>>>>>>> <ka...@gmail.com> 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
>>>>>>>>>>>>>> <ka...@gmail.com> 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
>>>>>>>>>>>>>>> <lh...@apache.org> 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
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>
>>> Craig L Russell
>>> Architect, Oracle
>>> http://db.apache.org/jdo
>>> 408 276-5638 mailto:Craig.Russell@oracle.com
>>> P.S. A good JDO? O, Gasp!
>>>
>>>
>
> Craig L Russell
> Architect, Oracle
> http://db.apache.org/jdo
> 408 276-5638 mailto:Craig.Russell@oracle.com
> P.S. A good JDO? O, Gasp!
>
>

Re: Preparing for our first release

Posted by Les Hazlewood <lh...@apache.org>.

Hi Crag,

I wasn't thinking it would be part of the maven repo directly, but it
is nicely packaged up there:

https://repository.apache.org/content/repositories/orgapacheshiro-004/org/apache/shiro/shiro-root/1.0.0-incubating/

You'll see the .zip and its signatures and checksums.

Cheers,

Les

On Thu, May 20, 2010 at 11:02 PM, Craig L Russell
<cr...@oracle.com> wrote:
>
> On May 20, 2010, at 7:32 PM, Kalle Korhonen wrote:
>
>> On Thu, May 20, 2010 at 5:57 PM, Craig L Russell
>> <cr...@oracle.com> wrote:
>>>
>>> You should put the release artifacts somewhere that folks can evaluate
>>> them,
>>> like in a user directory on people visible via the web, e.g.
>>> people.apache.org/~kaosko/shiro-001.
>>
>> That's exactly what the staging repository is for.
>
> Except that I didn't see anything in the staging repo that looks like a
> gzip/jar with checksums and signatures. Maybe you can point it out to me.
>
> Thanks,
>
> Craig
>>
>> Kalle
>>
>>
>>> On May 20, 2010, at 3:38 PM, Les Hazlewood wrote:
>>>
>>>> Awesome!
>>>>
>>>> But I just thought of a question:  what is/are our official release
>>>> artifact(s)?  Most people would expect a .zip so they can download
>>>> instead of being forced to use Maven, right?  We used to have a
>>>> jsecurity .zip and a jsecurity-with-dependencies.zip previously.  What
>>>> is good practice here in the ASF/Incubator?
>>>>
>>>> As I understand it, we need to distribute things like the LICENSE,
>>>> README, NOTICE files and other things as well - not just the .jar/
>>>> source .jar/JavaDoc .jars, right?  Our build doesn't currently make
>>>> these things, so I'm just trying to understand what is conventional
>>>> ASF practice.
>>>>
>>>> - Les
>>>>
>>>> On Thu, May 20, 2010 at 3:27 PM, Kalle Korhonen
>>>> <ka...@gmail.com> wrote:
>>>>>
>>>>> Here's the new 1.0.0-incubating staging url:
>>>>> https://repository.apache.org/content/repositories/orgapacheshiro-004/
>>>>>
>>>>> Kalle
>>>>>
>>>>>
>>>>> On Thu, May 20, 2010 at 1:46 PM, Les Hazlewood <lh...@apache.org>
>>>>> wrote:
>>>>>>
>>>>>> Ok, Kalle - issue has been committed to both trunk and the branch.
>>>>>> Tossing the ball back in to your court...
>>>>>>
>>>>>> On Thu, May 20, 2010 at 1:05 PM, Les Hazlewood <lh...@apache.org>
>>>>>> wrote:
>>>>>>>
>>>>>>> I'm running the new unit test now - fix looks good.  I'll commit in a
>>>>>>> minute and re-post when I've merged into the branch.
>>>>>>>
>>>>>>> On Thu, May 20, 2010 at 12:18 PM, Kalle Korhonen
>>>>>>> <ka...@gmail.com> wrote:
>>>>>>>>
>>>>>>>> Pushed the cart back to the top of the hill.
>>>>>>>>
>>>>>>>> Kalle
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, May 20, 2010 at 12:11 PM, Les Hazlewood <le...@hazlewood.com>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> No worries - merging is uber easy in Idea ;)  Thanks for doing the
>>>>>>>>> rollback!
>>>>>>>>>
>>>>>>>>> On Thu, May 20, 2010 at 12:06 PM, Kalle Korhonen
>>>>>>>>> <ka...@gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>> On Thu, May 20, 2010 at 12:00 PM, Les Hazlewood
>>>>>>>>>> <lh...@apache.org> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Yeah, I can fix it rather quickly I think.  Can you do the
>>>>>>>>>>> rollback
>>>>>>>>>>> while I fix it and write the test case? Also, I'm assuming I can
>>>>>>>>>>> add
>>>>>>>>>>> the fix to trunk?
>>>>>>>>>>
>>>>>>>>>> Yeah, I'll rollback and drop the staged release. You can fix it in
>>>>>>>>>> the
>>>>>>>>>> trunk, but the fix needs to be merged to the shiro-root-0.0.x
>>>>>>>>>> branch
>>>>>>>>>> (hey you asked for it :)
>>>>>>>>>>
>>>>>>>>>> Kalle
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> On Thu, May 20, 2010 at 11:47 AM, Kalle Korhonen
>>>>>>>>>>> <ka...@gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> 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
>>>>>>>>>>>> <lh...@apache.org> 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
>>>>>>>>>>>>> <ka...@gmail.com> 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
>>>>>>>>>>>>>> <ka...@gmail.com> 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
>>>>>>>>>>>>>>> <lh...@apache.org> 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
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>
>>> Craig L Russell
>>> Architect, Oracle
>>> http://db.apache.org/jdo
>>> 408 276-5638 mailto:Craig.Russell@oracle.com
>>> P.S. A good JDO? O, Gasp!
>>>
>>>
>
> Craig L Russell
> Architect, Oracle
> http://db.apache.org/jdo
> 408 276-5638 mailto:Craig.Russell@oracle.com
> P.S. A good JDO? O, Gasp!
>
>

Re: Preparing for our first release

Posted by Craig L Russell <cr...@oracle.com>.

On May 20, 2010, at 7:32 PM, Kalle Korhonen wrote:

> On Thu, May 20, 2010 at 5:57 PM, Craig L Russell
> <cr...@oracle.com> wrote:
>> You should put the release artifacts somewhere that folks can  
>> evaluate them,
>> like in a user directory on people visible via the web, e.g.
>> people.apache.org/~kaosko/shiro-001.
>
> That's exactly what the staging repository is for.

Except that I didn't see anything in the staging repo that looks like  
a gzip/jar with checksums and signatures. Maybe you can point it out  
to me.

Thanks,

Craig
>
> Kalle
>
>
>> On May 20, 2010, at 3:38 PM, Les Hazlewood wrote:
>>
>>> Awesome!
>>>
>>> But I just thought of a question:  what is/are our official release
>>> artifact(s)?  Most people would expect a .zip so they can download
>>> instead of being forced to use Maven, right?  We used to have a
>>> jsecurity .zip and a jsecurity-with-dependencies.zip previously.   
>>> What
>>> is good practice here in the ASF/Incubator?
>>>
>>> As I understand it, we need to distribute things like the LICENSE,
>>> README, NOTICE files and other things as well - not just the .jar/
>>> source .jar/JavaDoc .jars, right?  Our build doesn't currently make
>>> these things, so I'm just trying to understand what is conventional
>>> ASF practice.
>>>
>>> - Les
>>>
>>> On Thu, May 20, 2010 at 3:27 PM, Kalle Korhonen
>>> <ka...@gmail.com> wrote:
>>>>
>>>> Here's the new 1.0.0-incubating staging url:
>>>> https://repository.apache.org/content/repositories/orgapacheshiro-004/
>>>>
>>>> Kalle
>>>>
>>>>
>>>> On Thu, May 20, 2010 at 1:46 PM, Les Hazlewood <lhazlewood@apache.org 
>>>> >
>>>> wrote:
>>>>>
>>>>> Ok, Kalle - issue has been committed to both trunk and the branch.
>>>>> Tossing the ball back in to your court...
>>>>>
>>>>> On Thu, May 20, 2010 at 1:05 PM, Les Hazlewood <lhazlewood@apache.org 
>>>>> >
>>>>> wrote:
>>>>>>
>>>>>> I'm running the new unit test now - fix looks good.  I'll  
>>>>>> commit in a
>>>>>> minute and re-post when I've merged into the branch.
>>>>>>
>>>>>> On Thu, May 20, 2010 at 12:18 PM, Kalle Korhonen
>>>>>> <ka...@gmail.com> wrote:
>>>>>>>
>>>>>>> Pushed the cart back to the top of the hill.
>>>>>>>
>>>>>>> Kalle
>>>>>>>
>>>>>>>
>>>>>>> On Thu, May 20, 2010 at 12:11 PM, Les Hazlewood <les@hazlewood.com 
>>>>>>> >
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> No worries - merging is uber easy in Idea ;)  Thanks for  
>>>>>>>> doing the
>>>>>>>> rollback!
>>>>>>>>
>>>>>>>> On Thu, May 20, 2010 at 12:06 PM, Kalle Korhonen
>>>>>>>> <ka...@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>> On Thu, May 20, 2010 at 12:00 PM, Les Hazlewood
>>>>>>>>> <lh...@apache.org> wrote:
>>>>>>>>>>
>>>>>>>>>> Yeah, I can fix it rather quickly I think.  Can you do the  
>>>>>>>>>> rollback
>>>>>>>>>> while I fix it and write the test case? Also, I'm assuming  
>>>>>>>>>> I can
>>>>>>>>>> add
>>>>>>>>>> the fix to trunk?
>>>>>>>>>
>>>>>>>>> Yeah, I'll rollback and drop the staged release. You can fix  
>>>>>>>>> it in
>>>>>>>>> the
>>>>>>>>> trunk, but the fix needs to be merged to the shiro- 
>>>>>>>>> root-0.0.x branch
>>>>>>>>> (hey you asked for it :)
>>>>>>>>>
>>>>>>>>> Kalle
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> On Thu, May 20, 2010 at 11:47 AM, Kalle Korhonen
>>>>>>>>>> <ka...@gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>> 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
>>>>>>>>>>> <lh...@apache.org> 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
>>>>>>>>>>>> <ka...@gmail.com> 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
>>>>>>>>>>>>> <ka...@gmail.com> 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
>>>>>>>>>>>>>> <lh...@apache.org> 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
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>
>> Craig L Russell
>> Architect, Oracle
>> http://db.apache.org/jdo
>> 408 276-5638 mailto:Craig.Russell@oracle.com
>> P.S. A good JDO? O, Gasp!
>>
>>

Craig L Russell
Architect, Oracle
http://db.apache.org/jdo
408 276-5638 mailto:Craig.Russell@oracle.com
P.S. A good JDO? O, Gasp!

Re: Preparing for our first release

Posted by Kalle Korhonen <ka...@gmail.com>.

On Thu, May 20, 2010 at 5:57 PM, Craig L Russell
<cr...@oracle.com> wrote:
> You should put the release artifacts somewhere that folks can evaluate them,
> like in a user directory on people visible via the web, e.g.
> people.apache.org/~kaosko/shiro-001.

That's exactly what the staging repository is for.

Kalle


> On May 20, 2010, at 3:38 PM, Les Hazlewood wrote:
>
>> Awesome!
>>
>> But I just thought of a question:  what is/are our official release
>> artifact(s)?  Most people would expect a .zip so they can download
>> instead of being forced to use Maven, right?  We used to have a
>> jsecurity .zip and a jsecurity-with-dependencies.zip previously.  What
>> is good practice here in the ASF/Incubator?
>>
>> As I understand it, we need to distribute things like the LICENSE,
>> README, NOTICE files and other things as well - not just the .jar/
>> source .jar/JavaDoc .jars, right?  Our build doesn't currently make
>> these things, so I'm just trying to understand what is conventional
>> ASF practice.
>>
>> - Les
>>
>> On Thu, May 20, 2010 at 3:27 PM, Kalle Korhonen
>> <ka...@gmail.com> wrote:
>>>
>>> Here's the new 1.0.0-incubating staging url:
>>> https://repository.apache.org/content/repositories/orgapacheshiro-004/
>>>
>>> Kalle
>>>
>>>
>>> On Thu, May 20, 2010 at 1:46 PM, Les Hazlewood <lh...@apache.org>
>>> wrote:
>>>>
>>>> Ok, Kalle - issue has been committed to both trunk and the branch.
>>>> Tossing the ball back in to your court...
>>>>
>>>> On Thu, May 20, 2010 at 1:05 PM, Les Hazlewood <lh...@apache.org>
>>>> wrote:
>>>>>
>>>>> I'm running the new unit test now - fix looks good.  I'll commit in a
>>>>> minute and re-post when I've merged into the branch.
>>>>>
>>>>> On Thu, May 20, 2010 at 12:18 PM, Kalle Korhonen
>>>>> <ka...@gmail.com> wrote:
>>>>>>
>>>>>> Pushed the cart back to the top of the hill.
>>>>>>
>>>>>> Kalle
>>>>>>
>>>>>>
>>>>>> On Thu, May 20, 2010 at 12:11 PM, Les Hazlewood <le...@hazlewood.com>
>>>>>> wrote:
>>>>>>>
>>>>>>> No worries - merging is uber easy in Idea ;)  Thanks for doing the
>>>>>>> rollback!
>>>>>>>
>>>>>>> On Thu, May 20, 2010 at 12:06 PM, Kalle Korhonen
>>>>>>> <ka...@gmail.com> wrote:
>>>>>>>>
>>>>>>>> On Thu, May 20, 2010 at 12:00 PM, Les Hazlewood
>>>>>>>> <lh...@apache.org> wrote:
>>>>>>>>>
>>>>>>>>> Yeah, I can fix it rather quickly I think.  Can you do the rollback
>>>>>>>>> while I fix it and write the test case? Also, I'm assuming I can
>>>>>>>>> add
>>>>>>>>> the fix to trunk?
>>>>>>>>
>>>>>>>> Yeah, I'll rollback and drop the staged release. You can fix it in
>>>>>>>> the
>>>>>>>> trunk, but the fix needs to be merged to the shiro-root-0.0.x branch
>>>>>>>> (hey you asked for it :)
>>>>>>>>
>>>>>>>> Kalle
>>>>>>>>
>>>>>>>>
>>>>>>>>> On Thu, May 20, 2010 at 11:47 AM, Kalle Korhonen
>>>>>>>>> <ka...@gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>> 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
>>>>>>>>>> <lh...@apache.org> 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
>>>>>>>>>>> <ka...@gmail.com> 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
>>>>>>>>>>>> <ka...@gmail.com> 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
>>>>>>>>>>>>> <lh...@apache.org> 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
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>
> Craig L Russell
> Architect, Oracle
> http://db.apache.org/jdo
> 408 276-5638 mailto:Craig.Russell@oracle.com
> P.S. A good JDO? O, Gasp!
>
>

Re: Preparing for our first release

Posted by Craig L Russell <cr...@oracle.com>.

Hi Les,

Official release artifacts are the sources to the shiro project. The  
maven artifacts are considered optional binary releases.

The contents of http://svn.apache.org/repos/asf/incubator/shiro/trunk/  
which contains the LICENSE and NOTICE should be tar/zipped and  
optionally jarred. Then each of the tar/jar files should be  
checksummed and signed with a signing key using pgp, making sure the  
signing key is in the KEYS file.

You should put the release artifacts somewhere that folks can evaluate  
them, like in a user directory on people visible via the web, e.g.  
people.apache.org/~kaosko/shiro-001.

Craig

On May 20, 2010, at 3:38 PM, Les Hazlewood wrote:

> Awesome!
>
> But I just thought of a question:  what is/are our official release
> artifact(s)?  Most people would expect a .zip so they can download
> instead of being forced to use Maven, right?  We used to have a
> jsecurity .zip and a jsecurity-with-dependencies.zip previously.  What
> is good practice here in the ASF/Incubator?
>
> As I understand it, we need to distribute things like the LICENSE,
> README, NOTICE files and other things as well - not just the .jar/
> source .jar/JavaDoc .jars, right?  Our build doesn't currently make
> these things, so I'm just trying to understand what is conventional
> ASF practice.
>
> - Les
>
> On Thu, May 20, 2010 at 3:27 PM, Kalle Korhonen
> <ka...@gmail.com> wrote:
>> Here's the new 1.0.0-incubating staging url:
>> https://repository.apache.org/content/repositories/ 
>> orgapacheshiro-004/
>>
>> Kalle
>>
>>
>> On Thu, May 20, 2010 at 1:46 PM, Les Hazlewood  
>> <lh...@apache.org> wrote:
>>> Ok, Kalle - issue has been committed to both trunk and the branch.
>>> Tossing the ball back in to your court...
>>>
>>> On Thu, May 20, 2010 at 1:05 PM, Les Hazlewood <lhazlewood@apache.org 
>>> > wrote:
>>>> I'm running the new unit test now - fix looks good.  I'll commit  
>>>> in a
>>>> minute and re-post when I've merged into the branch.
>>>>
>>>> On Thu, May 20, 2010 at 12:18 PM, Kalle Korhonen
>>>> <ka...@gmail.com> wrote:
>>>>> Pushed the cart back to the top of the hill.
>>>>>
>>>>> Kalle
>>>>>
>>>>>
>>>>> On Thu, May 20, 2010 at 12:11 PM, Les Hazlewood  
>>>>> <le...@hazlewood.com> wrote:
>>>>>> No worries - merging is uber easy in Idea ;)  Thanks for doing  
>>>>>> the rollback!
>>>>>>
>>>>>> On Thu, May 20, 2010 at 12:06 PM, Kalle Korhonen
>>>>>> <ka...@gmail.com> wrote:
>>>>>>> On Thu, May 20, 2010 at 12:00 PM, Les Hazlewood <lhazlewood@apache.org 
>>>>>>> > wrote:
>>>>>>>> Yeah, I can fix it rather quickly I think.  Can you do the  
>>>>>>>> rollback
>>>>>>>> while I fix it and write the test case? Also, I'm assuming I  
>>>>>>>> can add
>>>>>>>> the fix to trunk?
>>>>>>>
>>>>>>> Yeah, I'll rollback and drop the staged release. You can fix  
>>>>>>> it in the
>>>>>>> trunk, but the fix needs to be merged to the shiro-root-0.0.x  
>>>>>>> branch
>>>>>>> (hey you asked for it :)
>>>>>>>
>>>>>>> Kalle
>>>>>>>
>>>>>>>
>>>>>>>> On Thu, May 20, 2010 at 11:47 AM, Kalle Korhonen
>>>>>>>> <ka...@gmail.com> wrote:
>>>>>>>>> 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 <lhazlewood@apache.org 
>>>>>>>>> > 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
>>>>>>>>>> <ka...@gmail.com> 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
>>>>>>>>>>> <ka...@gmail.com> 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 <lhazlewood@apache.org 
>>>>>>>>>>>> > 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
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>

Craig L Russell
Architect, Oracle
http://db.apache.org/jdo
408 276-5638 mailto:Craig.Russell@oracle.com
P.S. A good JDO? O, Gasp!

Re: Preparing for our first release

Posted by Tauren Mills <ta...@tauren.com>.

It looks like the maven artifacts to support the recent changes made
to the documentation (adding targetFilterLifecycle parameter to
DelegatingFilterProxy) have not been updated:
https://cwiki.apache.org/confluence/display/SHIRO/Spring

The latest snapshot available in the repository I'm using is 172, and
doesn't work if I make this change to my spring config (I get an
IllegalArgumentException):
https://repository.apache.org/content/repositories/snapshots/org/apache/shiro/shiro-core/1.0-incubating-SNAPSHOT/

I've been waiting for a new snapshot to appear, but it hasn't yet and
it's been several hours. Is this because snapshots are now going to
here instead?
https://repository.apache.org/content/repositories/orgapacheshiro-004/

I guess I'm just wanting to know what repository I should be using, or
if that is still in flux.

Thanks,
Tauren



On Thu, May 20, 2010 at 3:38 PM, Les Hazlewood <lh...@apache.org> wrote:
>
> Awesome!
>
> But I just thought of a question:  what is/are our official release
> artifact(s)?  Most people would expect a .zip so they can download
> instead of being forced to use Maven, right?  We used to have a
> jsecurity .zip and a jsecurity-with-dependencies.zip previously.  What
> is good practice here in the ASF/Incubator?
>
> As I understand it, we need to distribute things like the LICENSE,
> README, NOTICE files and other things as well - not just the .jar/
> source .jar/JavaDoc .jars, right?  Our build doesn't currently make
> these things, so I'm just trying to understand what is conventional
> ASF practice.
>
> - Les
>
> On Thu, May 20, 2010 at 3:27 PM, Kalle Korhonen
> <ka...@gmail.com> wrote:
> > Here's the new 1.0.0-incubating staging url:
> > https://repository.apache.org/content/repositories/orgapacheshiro-004/
> >
> > Kalle
> >
> >
> > On Thu, May 20, 2010 at 1:46 PM, Les Hazlewood <lh...@apache.org> wrote:
> >> Ok, Kalle - issue has been committed to both trunk and the branch.
> >> Tossing the ball back in to your court...
> >>
> >> On Thu, May 20, 2010 at 1:05 PM, Les Hazlewood <lh...@apache.org> wrote:
> >>> I'm running the new unit test now - fix looks good.  I'll commit in a
> >>> minute and re-post when I've merged into the branch.
> >>>
> >>> On Thu, May 20, 2010 at 12:18 PM, Kalle Korhonen
> >>> <ka...@gmail.com> wrote:
> >>>> Pushed the cart back to the top of the hill.
> >>>>
> >>>> Kalle
> >>>>
> >>>>
> >>>> On Thu, May 20, 2010 at 12:11 PM, Les Hazlewood <le...@hazlewood.com> wrote:
> >>>>> No worries - merging is uber easy in Idea ;)  Thanks for doing the rollback!
> >>>>>
> >>>>> On Thu, May 20, 2010 at 12:06 PM, Kalle Korhonen
> >>>>> <ka...@gmail.com> wrote:
> >>>>>> On Thu, May 20, 2010 at 12:00 PM, Les Hazlewood <lh...@apache.org> wrote:
> >>>>>>> Yeah, I can fix it rather quickly I think.  Can you do the rollback
> >>>>>>> while I fix it and write the test case? Also, I'm assuming I can add
> >>>>>>> the fix to trunk?
> >>>>>>
> >>>>>> Yeah, I'll rollback and drop the staged release. You can fix it in the
> >>>>>> trunk, but the fix needs to be merged to the shiro-root-0.0.x branch
> >>>>>> (hey you asked for it :)
> >>>>>>
> >>>>>> Kalle
> >>>>>>
> >>>>>>
> >>>>>>> On Thu, May 20, 2010 at 11:47 AM, Kalle Korhonen
> >>>>>>> <ka...@gmail.com> wrote:
> >>>>>>>> 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 <lh...@apache.org> 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
> >>>>>>>>> <ka...@gmail.com> 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
> >>>>>>>>>> <ka...@gmail.com> 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 <lh...@apache.org> 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
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> >

Re: Preparing for our first release

Posted by Les Hazlewood <lh...@apache.org>.

Awesome!

But I just thought of a question:  what is/are our official release
artifact(s)?  Most people would expect a .zip so they can download
instead of being forced to use Maven, right?  We used to have a
jsecurity .zip and a jsecurity-with-dependencies.zip previously.  What
is good practice here in the ASF/Incubator?

As I understand it, we need to distribute things like the LICENSE,
README, NOTICE files and other things as well - not just the .jar/
source .jar/JavaDoc .jars, right?  Our build doesn't currently make
these things, so I'm just trying to understand what is conventional
ASF practice.

- Les

On Thu, May 20, 2010 at 3:27 PM, Kalle Korhonen
<ka...@gmail.com> wrote:
> Here's the new 1.0.0-incubating staging url:
> https://repository.apache.org/content/repositories/orgapacheshiro-004/
>
> Kalle
>
>
> On Thu, May 20, 2010 at 1:46 PM, Les Hazlewood <lh...@apache.org> wrote:
>> Ok, Kalle - issue has been committed to both trunk and the branch.
>> Tossing the ball back in to your court...
>>
>> On Thu, May 20, 2010 at 1:05 PM, Les Hazlewood <lh...@apache.org> wrote:
>>> I'm running the new unit test now - fix looks good.  I'll commit in a
>>> minute and re-post when I've merged into the branch.
>>>
>>> On Thu, May 20, 2010 at 12:18 PM, Kalle Korhonen
>>> <ka...@gmail.com> wrote:
>>>> Pushed the cart back to the top of the hill.
>>>>
>>>> Kalle
>>>>
>>>>
>>>> On Thu, May 20, 2010 at 12:11 PM, Les Hazlewood <le...@hazlewood.com> wrote:
>>>>> No worries - merging is uber easy in Idea ;)  Thanks for doing the rollback!
>>>>>
>>>>> On Thu, May 20, 2010 at 12:06 PM, Kalle Korhonen
>>>>> <ka...@gmail.com> wrote:
>>>>>> On Thu, May 20, 2010 at 12:00 PM, Les Hazlewood <lh...@apache.org> wrote:
>>>>>>> Yeah, I can fix it rather quickly I think.  Can you do the rollback
>>>>>>> while I fix it and write the test case? Also, I'm assuming I can add
>>>>>>> the fix to trunk?
>>>>>>
>>>>>> Yeah, I'll rollback and drop the staged release. You can fix it in the
>>>>>> trunk, but the fix needs to be merged to the shiro-root-0.0.x branch
>>>>>> (hey you asked for it :)
>>>>>>
>>>>>> Kalle
>>>>>>
>>>>>>
>>>>>>> On Thu, May 20, 2010 at 11:47 AM, Kalle Korhonen
>>>>>>> <ka...@gmail.com> wrote:
>>>>>>>> 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 <lh...@apache.org> 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
>>>>>>>>> <ka...@gmail.com> 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
>>>>>>>>>> <ka...@gmail.com> 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 <lh...@apache.org> 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
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

Re: Preparing for our first release

Posted by Kalle Korhonen <ka...@gmail.com>.

Here's the new 1.0.0-incubating staging url:
https://repository.apache.org/content/repositories/orgapacheshiro-004/

Kalle


On Thu, May 20, 2010 at 1:46 PM, Les Hazlewood <lh...@apache.org> wrote:
> Ok, Kalle - issue has been committed to both trunk and the branch.
> Tossing the ball back in to your court...
>
> On Thu, May 20, 2010 at 1:05 PM, Les Hazlewood <lh...@apache.org> wrote:
>> I'm running the new unit test now - fix looks good.  I'll commit in a
>> minute and re-post when I've merged into the branch.
>>
>> On Thu, May 20, 2010 at 12:18 PM, Kalle Korhonen
>> <ka...@gmail.com> wrote:
>>> Pushed the cart back to the top of the hill.
>>>
>>> Kalle
>>>
>>>
>>> On Thu, May 20, 2010 at 12:11 PM, Les Hazlewood <le...@hazlewood.com> wrote:
>>>> No worries - merging is uber easy in Idea ;)  Thanks for doing the rollback!
>>>>
>>>> On Thu, May 20, 2010 at 12:06 PM, Kalle Korhonen
>>>> <ka...@gmail.com> wrote:
>>>>> On Thu, May 20, 2010 at 12:00 PM, Les Hazlewood <lh...@apache.org> wrote:
>>>>>> Yeah, I can fix it rather quickly I think.  Can you do the rollback
>>>>>> while I fix it and write the test case? Also, I'm assuming I can add
>>>>>> the fix to trunk?
>>>>>
>>>>> Yeah, I'll rollback and drop the staged release. You can fix it in the
>>>>> trunk, but the fix needs to be merged to the shiro-root-0.0.x branch
>>>>> (hey you asked for it :)
>>>>>
>>>>> Kalle
>>>>>
>>>>>
>>>>>> On Thu, May 20, 2010 at 11:47 AM, Kalle Korhonen
>>>>>> <ka...@gmail.com> wrote:
>>>>>>> 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 <lh...@apache.org> 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
>>>>>>>> <ka...@gmail.com> 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
>>>>>>>>> <ka...@gmail.com> 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 <lh...@apache.org> 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
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

Re: Preparing for our first release

Posted by Les Hazlewood <lh...@apache.org>.

Ok, Kalle - issue has been committed to both trunk and the branch.
Tossing the ball back in to your court...

On Thu, May 20, 2010 at 1:05 PM, Les Hazlewood <lh...@apache.org> wrote:
> I'm running the new unit test now - fix looks good.  I'll commit in a
> minute and re-post when I've merged into the branch.
>
> On Thu, May 20, 2010 at 12:18 PM, Kalle Korhonen
> <ka...@gmail.com> wrote:
>> Pushed the cart back to the top of the hill.
>>
>> Kalle
>>
>>
>> On Thu, May 20, 2010 at 12:11 PM, Les Hazlewood <le...@hazlewood.com> wrote:
>>> No worries - merging is uber easy in Idea ;)  Thanks for doing the rollback!
>>>
>>> On Thu, May 20, 2010 at 12:06 PM, Kalle Korhonen
>>> <ka...@gmail.com> wrote:
>>>> On Thu, May 20, 2010 at 12:00 PM, Les Hazlewood <lh...@apache.org> wrote:
>>>>> Yeah, I can fix it rather quickly I think.  Can you do the rollback
>>>>> while I fix it and write the test case? Also, I'm assuming I can add
>>>>> the fix to trunk?
>>>>
>>>> Yeah, I'll rollback and drop the staged release. You can fix it in the
>>>> trunk, but the fix needs to be merged to the shiro-root-0.0.x branch
>>>> (hey you asked for it :)
>>>>
>>>> Kalle
>>>>
>>>>
>>>>> On Thu, May 20, 2010 at 11:47 AM, Kalle Korhonen
>>>>> <ka...@gmail.com> wrote:
>>>>>> 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 <lh...@apache.org> 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
>>>>>>> <ka...@gmail.com> 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
>>>>>>>> <ka...@gmail.com> 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 <lh...@apache.org> 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
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

Re: Preparing for our first release

Posted by Les Hazlewood <lh...@apache.org>.

I'm running the new unit test now - fix looks good.  I'll commit in a
minute and re-post when I've merged into the branch.

On Thu, May 20, 2010 at 12:18 PM, Kalle Korhonen
<ka...@gmail.com> wrote:
> Pushed the cart back to the top of the hill.
>
> Kalle
>
>
> On Thu, May 20, 2010 at 12:11 PM, Les Hazlewood <le...@hazlewood.com> wrote:
>> No worries - merging is uber easy in Idea ;)  Thanks for doing the rollback!
>>
>> On Thu, May 20, 2010 at 12:06 PM, Kalle Korhonen
>> <ka...@gmail.com> wrote:
>>> On Thu, May 20, 2010 at 12:00 PM, Les Hazlewood <lh...@apache.org> wrote:
>>>> Yeah, I can fix it rather quickly I think.  Can you do the rollback
>>>> while I fix it and write the test case? Also, I'm assuming I can add
>>>> the fix to trunk?
>>>
>>> Yeah, I'll rollback and drop the staged release. You can fix it in the
>>> trunk, but the fix needs to be merged to the shiro-root-0.0.x branch
>>> (hey you asked for it :)
>>>
>>> Kalle
>>>
>>>
>>>> On Thu, May 20, 2010 at 11:47 AM, Kalle Korhonen
>>>> <ka...@gmail.com> wrote:
>>>>> 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 <lh...@apache.org> 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
>>>>>> <ka...@gmail.com> 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
>>>>>>> <ka...@gmail.com> 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 <lh...@apache.org> 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
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

Re: Preparing for our first release

Posted by Kalle Korhonen <ka...@gmail.com>.

Pushed the cart back to the top of the hill.

Kalle


On Thu, May 20, 2010 at 12:11 PM, Les Hazlewood <le...@hazlewood.com> wrote:
> No worries - merging is uber easy in Idea ;)  Thanks for doing the rollback!
>
> On Thu, May 20, 2010 at 12:06 PM, Kalle Korhonen
> <ka...@gmail.com> wrote:
>> On Thu, May 20, 2010 at 12:00 PM, Les Hazlewood <lh...@apache.org> wrote:
>>> Yeah, I can fix it rather quickly I think.  Can you do the rollback
>>> while I fix it and write the test case? Also, I'm assuming I can add
>>> the fix to trunk?
>>
>> Yeah, I'll rollback and drop the staged release. You can fix it in the
>> trunk, but the fix needs to be merged to the shiro-root-0.0.x branch
>> (hey you asked for it :)
>>
>> Kalle
>>
>>
>>> On Thu, May 20, 2010 at 11:47 AM, Kalle Korhonen
>>> <ka...@gmail.com> wrote:
>>>> 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 <lh...@apache.org> 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
>>>>> <ka...@gmail.com> 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
>>>>>> <ka...@gmail.com> 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 <lh...@apache.org> 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
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

Re: Preparing for our first release

Posted by Les Hazlewood <le...@hazlewood.com>.

No worries - merging is uber easy in Idea ;)  Thanks for doing the rollback!

On Thu, May 20, 2010 at 12:06 PM, Kalle Korhonen
<ka...@gmail.com> wrote:
> On Thu, May 20, 2010 at 12:00 PM, Les Hazlewood <lh...@apache.org> wrote:
>> Yeah, I can fix it rather quickly I think.  Can you do the rollback
>> while I fix it and write the test case? Also, I'm assuming I can add
>> the fix to trunk?
>
> Yeah, I'll rollback and drop the staged release. You can fix it in the
> trunk, but the fix needs to be merged to the shiro-root-0.0.x branch
> (hey you asked for it :)
>
> Kalle
>
>
>> On Thu, May 20, 2010 at 11:47 AM, Kalle Korhonen
>> <ka...@gmail.com> wrote:
>>> 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 <lh...@apache.org> 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
>>>> <ka...@gmail.com> 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
>>>>> <ka...@gmail.com> 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 <lh...@apache.org> 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
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

Re: Preparing for our first release

Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.

On May 20, 2010, at 12:06 PM, Kalle Korhonen wrote:

> On Thu, May 20, 2010 at 12:00 PM, Les Hazlewood <lh...@apache.org> wrote:
>> Yeah, I can fix it rather quickly I think.  Can you do the rollback
>> while I fix it and write the test case? Also, I'm assuming I can add
>> the fix to trunk?
> 
> Yeah, I'll rollback and drop the staged release. You can fix it in the
> trunk, but the fix needs to be merged to the shiro-root-0.0.x branch
> (hey you asked for it :)

FYI, since you just you two guys fiddling around with things at the moment, it's ok to trash the branch and tags.

But you are correct, normally you would merge the fix into the branch and trunk.

Regards,
Alan

Re: Preparing for our first release

Posted by Kalle Korhonen <ka...@gmail.com>.

On Thu, May 20, 2010 at 12:00 PM, Les Hazlewood <lh...@apache.org> wrote:
> Yeah, I can fix it rather quickly I think.  Can you do the rollback
> while I fix it and write the test case? Also, I'm assuming I can add
> the fix to trunk?

Yeah, I'll rollback and drop the staged release. You can fix it in the
trunk, but the fix needs to be merged to the shiro-root-0.0.x branch
(hey you asked for it :)

Kalle


> On Thu, May 20, 2010 at 11:47 AM, Kalle Korhonen
> <ka...@gmail.com> wrote:
>> 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 <lh...@apache.org> 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
>>> <ka...@gmail.com> 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
>>>> <ka...@gmail.com> 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 <lh...@apache.org> 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
>>>>>>
>>>>>
>>>>
>>>
>>
>

Re: Preparing for our first release

Posted by Les Hazlewood <lh...@apache.org>.

Yeah, I can fix it rather quickly I think.  Can you do the rollback
while I fix it and write the test case? Also, I'm assuming I can add
the fix to trunk?

On Thu, May 20, 2010 at 11:47 AM, Kalle Korhonen
<ka...@gmail.com> wrote:
> 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 <lh...@apache.org> 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
>> <ka...@gmail.com> 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
>>> <ka...@gmail.com> 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 <lh...@apache.org> 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
>>>>>
>>>>
>>>
>>
>

Re: Preparing for our first release

Posted by Kalle Korhonen <ka...@gmail.com>.

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 <lh...@apache.org> 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
> <ka...@gmail.com> 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
>> <ka...@gmail.com> 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 <lh...@apache.org> 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
>>>>
>>>
>>
>

Re: Preparing for our first release

Posted by Les Hazlewood <lh...@apache.org>.

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
<ka...@gmail.com> 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
> <ka...@gmail.com> 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 <lh...@apache.org> 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
>>>
>>
>

Re: Preparing for our first release

Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.

On May 21, 2010, at 7:32 AM, Kalle Korhonen wrote:

> On Fri, May 21, 2010 at 6:41 AM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>> On May 20, 2010, at 10:53 AM, Kalle Korhonen wrote:
>> Looked at http://incubator.apache.org/shiro/static/1.0.0-incubating/team-list.html.
>> It should contain all the committers on the team.  Can we update this?
> 
> Committers need to modify Shiro's root pom and add their info.

Fair enough.  Let's put out an announcement so that developers know that they need to do this.


Regards,
Alan

Re: Preparing for our first release

Posted by Kalle Korhonen <ka...@gmail.com>.

On Fri, May 21, 2010 at 6:41 AM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
> On May 20, 2010, at 10:53 AM, Kalle Korhonen wrote:
> Looked at http://incubator.apache.org/shiro/static/1.0.0-incubating/team-list.html.
> It should contain all the committers on the team.  Can we update this?

Committers need to modify Shiro's root pom and add their info.

Kalle

Re: Preparing for our first release

Posted by Les Hazlewood <lh...@apache.org>.

Yeah, I just added that as a placeholder for when we 'got around to
it'.  In retrospect, I think I should remove it in the interim and
rely on the root POM listing developers to minimize the delay in
getting all things updated.  Is this ok?

On Fri, May 21, 2010 at 6:41 AM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>
> On May 20, 2010, at 10:53 AM, Kalle Korhonen 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.
>
> Looked at http://incubator.apache.org/shiro/static/1.0.0-incubating/team-list.html.
>
> It should contain all the committers on the team.  Can we update this?
>
>
> Regards,
> Alan
>
>

Re: Preparing for our first release

Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.

On May 20, 2010, at 10:53 AM, Kalle Korhonen 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.

Looked at http://incubator.apache.org/shiro/static/1.0.0-incubating/team-list.html.

It should contain all the committers on the team.  Can we update this?

Regards,
Alan

Re: Preparing for our first release

Posted by Kalle Korhonen <ka...@gmail.com>.

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
<ka...@gmail.com> 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 <lh...@apache.org> 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
>>
>

Re: Preparing for our first release

Posted by Kalle Korhonen <ka...@gmail.com>.

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 <lh...@apache.org> 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
>