How about we have at least two branches then - "shiny new unstable code" and "scared hand-wringing old woman code"... LOL...

Phil N8VB


On 11/10/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>> As many of us do.
>
> I am not sure what you are trying to say here... do you think that somehow
> installing the .NET 2.0 SDK you are going to make your machine unstable?
>
>
> Phil N8VB
>

Well, yes, actually.  It is just possible.  It may be that, by default,
code uses the same level of .Net they compiled with and so it doesn't
matter.  But, it is hardly unknown for there to be other schemes.  It may
not take long before code is "dual version aware" and that may create some
unexpected instability in other applications.  In Java, it is very easy to
write such code.  I don't know about .Net yet, but easy or hard, it may
well happen, because in more complex environments, upgrades really don't
happen easily and some apps will choose to cope with two versions of .Net,
however that has to be done.  It would hardly be a first in the industry
for code to optionally execute function based on the available underlying
version.  I've seen that kind of code all my life.  Whether it is a few
added DLLs or even a whole different executable, someone will do it and
probably multiple someones.

For developer types, none of this is a very big deal.  For nondevelopers,
why should we risk any exposure to this sort of thing, however small, just
for our application?  At least, why should we do so until we actually
start using the .Net 2.0 function in a big way?  I simply advise that we
not go uplevel for some simple or casual thing, but make it a kind of step
function where we are doing either one very major enhancement or a fair
number of little ones before requring everyone to change levels.
Conversely, if we can make the next several things work easily without
invoking the new function, I suggest we do so.  At least in the
"production" version.  The betas can go uplevel when we wish provided we
don't back into a casual .Net 2.0 strategy.

That's pretty ordinary change management in my experience of these things.
I do it, my customers do it.

Software is always two steps forward, one step back in my experience of it
and end users, in particular, often only "see" the one step back part if
it breaks something, anything.  I've seen way, way too much stuff that
couldn't possibly happen. . .happen.  Especially when the code in question
is in the million line of code plus range.  Scale matters.



Larry  WO0Z




--
Philip A Covington
http://www.philcovington.com

Reply via email to