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

[Jeffrey Altman]

Sam Hartman wrote:
>
> 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.
I would recommend that parallel development take place on a branch cut
from 1.6.

I am attaching a document that describes the work that has been
performed on NIM 2.0 and that partially describes what remains to be
accomplished.   The redesign work on the NIM API in order to maintain
backward compatibility with existing credential providers shipped by
third parties and to anticipate future needs has obviously taken longer
than expected.

Asanka will follow up next week with a more detailed description of the
remaining pieces that must be developed.

In my opinion, it is perfectly acceptable for the initial X.509 identity
provider to be shipped as an add-on to KFW.

Jeffrey Altman

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: nim2-status.txt
Url: http://mailman.mit.edu/pipermail/kfwdev/attachments/20071116/38e7067c/attachment.txt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3355 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mailman.mit.edu/pipermail/kfwdev/attachments/20071116/38e7067c/attachment.bin