Stanley Stanev wrote:
> you still want to deprecate interfaces, you do not want to support old
> versions forever...
>
> you notify customers, give them time to start using the new ones, and
> stop supporting deprecated ones at the specified time
>
> of course, all above in case you are not able to handle things without
> contract change
I generally believe that supporting an interface, "forever", is not a bad
thing.
At lease it's not bad as long as it doesn't impact the business proposition.
We
have programming interfaces that should have been deprecated decades ago. The
C
language, in particular, has functions which never should of existed. The K &
R
string implementations, were examples, but ended up being standardized, and now
we have all kinds of problems with viruses related to buffere overruns.
The issue is that C, is not a versioned platform. There's not a drop off spot
for some feature, and a pickup of a new feature. So, the design of that
environment was never really based on versioning, enhancements, or other such
things. Instead, it's a n environment totally based on piece part updates
(language based libraries).
Some programming languages/platforms provide a more uniform mechanism for
version control of components. Java, lets you use classloaders as an isolation
mechanism for data that is shared in focused parts of the system.
Gregg Wonderly
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/service-orientated-architecture/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/service-orientated-architecture/join
(Yahoo! ID required)
<*> To change settings via email:
mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
