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 Fri, 04 Nov 2016 20:50:42 GMT
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