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