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) > > > > > >
