+1 on the release timing and management. I also think that a 0.9 before a 1.0 would make it easier for us to work through packaging changes and any other "1.0" type requirements in a more isolated fashion.
On 3/8/16, 9:59 AM, "larry mccay" <[email protected]> wrote: >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 >>
