KFW releases off the trunk will become harder as 1.7 features start getting used

[Alexandra Ellwood]

I am working on a CCAPI v2 shim layer for the new CCAPI.  Should have  
it ready for testing by the end of the week.


On Feb 6, 2008, at 2:05 PM, Jeffrey Altman wrote:

> NIM2 is not dependent upon 1.7.  However, given the recent  
> discussions of
> the new credential cache not supporting CCAPIv2 there will be a  
> break in
> functionality of NIM and NIM2 if the new CCAPI is deployed without  
> re-writing
> the NIM Kerberos v5 provider.  (Also note that the KFW klist.exe is  
> also
> dependent upon CCAPIv2.)
>
> As long as the 1.7 libraries do not break backward compatibility,  
> there is
> no issue for NIM2 (and other applications that depend on MIT  
> Kerberos.)
> If there is a break in backward compatibility, it will be harder to  
> deploy
> a new krb5 NIM provider that supports both the old and the new  
> libraries.
>
> Jeffrey Altman
> Secure Endpoints Inc.
>
>
> Kevin Koch wrote:
>> Jeff --
>>
>> Considering the later discussion of NIM2 being independent of the  
>> Kerberos
>> 1.7 libraries, is 1.7 a non-issue for NIM2?
>>
>> Thanks.
>>
>> Kevin
>>> -----Original Message-----
>>> From: kfwdev-bounces at MIT.EDU [mailto:kfwdev-bounces at MIT.EDU] On  
>>> Behalf Of
>>> Sam Hartman
>>> Sent: Monday, November 12, 2007 5:43 PM
>>> To: kfwdev at mit.edu
>>> Subject: KFW releases off the trunk will become harder as 1.7  
>>> features
>>> startgetting used
>>>
>>> One long-running aspect of our release process is that the trunk is
>>> allowed to take advantage of features on the trunk.  In particular
>>> this means things like as we get new implementations of CCAPI, KIM  
>>> and
>>> other APIs available, we'll want to start using them.  And we don't
>>> generally support backward compatibility for this sort of change.
>>>
>>> One consequence of this is that we may start running into cases  
>>> where
>>> specific changes to KFW will end up depending on the 1.7 release or
>>> at least the 1.7 release branch.  I'd expect to get to a point in a
>>> few months where any significant changes to KFW would depend on 1.7.
>>>
>>> We've been traditionally very reluctant to pull significant features
>>> for future releases back to old release branches.  I'd expect Tom to
>>> continue that practice.  We may develop more well defined guidelines
>>> for when pull-ups are appropriate, but I would expect anything we  
>>> came
>>> to consensus on to be relatively conservative in this regard.
>>>
>>> There may be projects that we want to consider and try and avoid
>>> blocking behind 1.7.  I think that quite soon, we're going to want  
>>> to
>>> establish a deadline for any such project to be proposed and for  
>>> us to
>>> at least have the community discussion about whether we want to  
>>> avoid
>>> blocking the projects behind 1.7.
>>>
>>> Kevin, I'd appreciate it if you could work with Jeff and anyone else
>>> who has an opinion and decide on a deadline by which projects that
>>> want to avoid being blocked behind 1.7 must be proposed.
>>>
>>> I think that shorter than two weeks from today would be unrealistic.
>>> I think that a deadline beyond Jan 15 would probably be too long.
>>>
>>>
>>> One specific concern I have is the NIM 2.0 work.  There was a  
>>> project
>>> proposal over the summer for the user experience.  However there
>>> hasn't been any proposals made regarding technical impact or how the
>>> user experience would be accomplished.
>>>
>>> That's fine, but until such proposals are reviewed, we as a group
>>> won't be in a position to avoid taking NIM 2.0 design into account  
>>> and
>>> avoid making things harder for NIM 2.0.
>>>
>>> Thanks for your consideration
>>>
>>> --Sam
>> ...
>>
>> _______________________________________________
>> kfwdev mailing list
>> kfwdev at mit.edu
>> http://mailman.mit.edu/mailman/listinfo/kfwdev
> _______________________________________________
> kfwdev mailing list
> kfwdev at mit.edu
> http://mailman.mit.edu/mailman/listinfo/kfwdev

--lxs

Alexandra Ellwood <lxs at mit.edu>
MIT Kerberos Development Team
<http://mit.edu/lxs/www>