Sounds good! Thanks for the summary. -- Les
On Tue, Nov 8, 2016 at 7:10 AM, Brian Demers <[email protected]> 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 <[email protected]> > wrote: > > > Cool. +1 for me in that case :) > > > > -- > > Les > > > > On Fri, Nov 4, 2016 at 1:50 PM, Brian Demers <[email protected]> > > 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 <[email protected]> > > > 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 <[email protected]> > > > 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) > > > > > > > > > > > > > > >
