shiro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Demers <brian.dem...@gmail.com>
Subject Re: Preparing for our first release
Date Fri, 21 May 2010 02:08:47 GMT
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 <GHogan@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 <lhazlewood@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
> <craig.russell@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
> >> <kalle.o.korhonen@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
> >>>>> <kalle.o.korhonen@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
> >>>>>>> <kalle.o.korhonen@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
> >>>>>>>>> <kalle.o.korhonen@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
> >>>>>>>>>>> <kalle.o.korhonen@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
> >>>>>>>>>>>> <kalle.o.korhonen@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!
> >
> >
>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message