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: [VOTE] Change HEAD to 1.4.x
Date Tue, 08 Nov 2016 15:10:06 GMT
To wrap this up:

* Master is now 1.4
* openid4j support is now in this PR: #46
<https://github.com/apache/shiro/pull/46> (if anyone is interested in
picking that up)
* faces support was pulled out of master for the time being, and will be
managed in this repo: deluan/shiro-faces
<https://github.com/deluan/shiro-faces>
* The 1.4.x branch was deleted, the previous RC tag remains though:
shiro-root-1.4.0-RC1-release-vote1
<https://github.com/apache/shiro/tree/shiro-root-1.4.0-RC1-release-vote1>

Of note, I found and corrected a couple non-backwards compatible items
while moving these bits around:
* An unused constructor was removed 6eb070f4
<https://github.com/apache/shiro/commit/6eb070f4ac6a882eb01ce188701b40d0017ae2d0>
* CollectionUtils has a dependency on PrincipalCollection, and was moved
back to shiro-core.  This method was marked deprecated, and all usages of
CollectionUtils in the new modules (lang, cache, etc) have been updated.
This class WILL be moved back to lang for 2.0 d44204a4
<https://github.com/apache/shiro/commit/d44204a4378f73e17be2e58097ba09d33c1cff3e>


I plan on spinning up 1.4 RC2 release tomorrow. If anyone has any feedback
let me know.



On Fri, Nov 4, 2016 at 7:39 PM, Les Hazlewood <lhazlewood@apache.org> wrote:

> Cool.  +1 for me in that case :)
>
> --
> Les
>
> On Fri, Nov 4, 2016 at 1:50 PM, Brian Demers <brian.demers@gmail.com>
> wrote:
>
> > To me that would be ideal, but we would end up in a force push/pull
> > scenario for anyone tracking the current master.
> >
> > Though now that you mention it, we could keep the current master. pulling
> > out the couple commits I listed above, and just update the versions to
> > 1.4.  That would simplify/reduce all of those steps.  I'll take another
> > look and make sure there is nothing that effects the version semver wise,
> > but this seems like better path forward.
> >
> > On Fri, Nov 4, 2016 at 3:53 PM, Les Hazlewood <lhazlewood@apache.org>
> > wrote:
> >
> > > I'm good with #1, but I'm a bit uncomfortable not having a master
> branch
> > -
> > > just because it feels weird to me.  Why not have 1.4.x just be master?
> > and
> > > delete the 1.4.x branch?
> > >
> > > In the past, we've typically just created new maj.(currentMin-1).x
> > branches
> > > if/when we needed them, and maj.(currentMin).x was master.
> > >
> > > Thoughts?
> > >
> > > --
> > > Les
> > >
> > > On Fri, Nov 4, 2016 at 10:35 AM, Brian Demers <bdemers@apache.org>
> > wrote:
> > >
> > > > I think everything from master (2.0-alpha) has been merged into 1.4
> > > except
> > > > for a couple things: the biggest of which is breaking up the modules
> > into
> > > > smaller bits, and the following two commits
> > > >
> > > > *3a9207fd82eefd867924fcbcdd449bdbe050bb41* Incomplete - SHIRO-21:
> Add
> > > > OpenId as an authentication mechanism - change RelyingPartyRealm to
> > > extend
> > > > AuthenticatingRealm only, openid isn't an authorization protocol
> > > >
> > > > *8bdf23f5de4d502eae7354319887c05cb38c179b* SHIRO-206: Added initial
> > > > implementation based on patch  <<<<< Faces
> > > >
> > > > The branches were split back in SVN, so dissecting the changes wasn't
> > > > trivial.  For the sake of this discussion/vote lets assume this is
> the
> > > > case, (but double check before any work is done)
> > > >
> > > > I propose we:
> > > > 1. back port the module splitting to 1.4.
> > > >   (this is a semver gray area, but all package names are unchanged,
> and
> > > > Maven dependency's resolution ensures all of the classes are
> available
> > > the
> > > > same way as today)
> > > > 2. Remove faces module from master (there is a separate thread on the
> > on
> > > > going support of this, and we can pull it back in at a later date)
> > > > 3. Move the OpenId commit above to a 'WIP' pull request
> > > > 4. Remove the 'master' branch, and change the HEAD ref (default
> branch)
> > > to
> > > > be 1.4.x
> > > > 5. Release 1.4
> > > >
> > > > 6+. Create a new 2.0.x branch off of 1.4.x ( Update to JDK 1.8, etc )
> > > >
> > > >
> > > > Reasons:
> > > > * Cherry picking to master is a bit of a pain
> > > > * People are grabbing the current master, i think our current default
> > > > branch _should_ be what the next minor release branch is.
> > > > * Clean history, the old svn commits between the old trunk, and 1.2.x
> > > were
> > > > did not always use the same commit message, and the git-svn-id are
> > always
> > > > different between the branches.
> > > >
> > > >
> > > > Vote is open for lazy consensus
> > > > <http://www.apache.org/foundation/voting.html#LazyConsensus> for
72
> > > hours.
> > > > (Personally I'd like to hear thoughts around #1 and #4, as the others
> > are
> > > > just side effects of doing those actions)
> > > >
> > >
> >
>

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