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

[Sam Hartman]

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