shiro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Les Hazlewood <lhazlew...@apache.org>
Subject Re: [VOTE] Change HEAD to 1.4.x
Date Tue, 08 Nov 2016 17:27:08 GMT
Sounds good!  Thanks for the summary.

--
Les

On Tue, Nov 8, 2016 at 7:10 AM, Brian Demers <brian.demers@gmail.com> wrote:

> 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/6eb070f4ac6a882eb01ce188701b40
> d0017ae2d0>
> * 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/d44204a4378f73e17be2e58097ba09
> d33c1cff3e>
>
>
> 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