I agree. Perhaps, we can target a very focused 0.10.0 -> 1.0 followup release where we can clearly identify any such breakages and help with the migration via docs or tools or whatever?
On Tue, Mar 8, 2016 at 9:57 AM, Kevin Minder <[email protected]> wrote: > I'm on the fence about an 0.9 vs a 1.0. A 1.0 means fixing the package > names to me mostly. Breaking backwards compatibility is always a difficult > decision. > > > > > On 3/8/16, 9:55 AM, "Kevin Minder" <[email protected]> wrote: > > >Larry, > >I'm +1 on the content, timing and you being RM. > >Kevin. > > > > > > > > > >On 3/8/16, 9:22 AM, "larry mccay" <[email protected]> wrote: > > > >>All - > >> > >>I'd like to volunteer to be the release manager for the 0.9.0 release > >>unless someone else would like to take it instead. > >> > >>In addition, I think that we need to scope the release and driving > usecases > >>and a target date for the release. > >> > >>We currently have ~25 JIRAs slated for 0.9.0 and most fall into one or > more > >>of the following categories: > >> > >>* dependency upgrades and related fixes > >>* proxying of UIs for Ambari and Ranger and related issues > >>* the hosting of web applications > >>* the addition of an application for a default KnoxSSO form based login > >>* PAM authentication provider - MISSING DOCs and TESTs > >>* various bug fixes and incremental improvements > >> > >>It seems that around half of these are already set to fixed. > >> > >>If there are additional issues that folks would like to get into the > 0.9.0 > >>release then we should discuss anything that would require a sizable > change > >>and file JIRAs for them asap. > >> > >>I believe that from the above categories that we can adjust the driving > >>usecases from the 0.8.0 release to reflect the shift of focus from > external > >>applications to: > >> > >>1. SSO participation by applications like Ranger and Ambari while being > >>proxied through the gateway. > >> > >>2. Authentication natively done by Ranger and Ambari applications while > >>being proxied through Knox. > >> > >>3. the usecase of a custom application like the Knoxplorer sample can now > >>be hosted by Knox and this needs to be covered and tested with KnoxSSO. > >> > >>4. Default Knox authentication with form based application as KnoxSSO > IDP. > >> > >>5. any additional API support and various features and improvements. > >> > >>It seems to me that we could start considering a 1.0 release. If this > seems > >>like a reasonable time to do that then we should open up discussion for > any > >>additional improvements or changes that we'd want to include in order to > >>make it our 1.0. > >> > >>Given the above scope and driving usecases, I'd like to propose an end of > >>March release. > >> > >>Thoughts? > >> > >>thanks, > >> > >>--larry >
