> > Once you go that route, you must ALWAYS go that route, for every change,
or
> > your efforts are more-or-less pointless. 90% backward compatibility
isn't
> > really much better than 0%. If the user has to edit a config file to
> > upgrade, it's a pain.
Well, of course you don't have to always do it. As in, always maintain the
deprecaited feature.
What you DO have to always do is announce that in release n+ >1 that feature
X will be removed and replaced by feature Y, and that for the n>1
intervening releases BOTH versions of the feature will be supported.
This gives people time to come up on the new version using existing syntax,
and find the problems with the new syntax, if any. If problems exist they
can stay with the old feature, and hopefully in the following release, or a
patch of the current release, the problems with the new feature will be
fixed.
But the trick here is that at least one or more releases will contain both
features. This is different than saying "feature X will be replaced at the
next major release. We'll tell you what to use in its place in the release
announcement for the next major release."
> Making it impossible to upgrade without downtime is bad. With backwards
> compat you allow people to seamlessly upgrade, and migrate their changes
> on a live system. Without it, you force people to shutdown and convert
> their entire system in-place, before upgrading. That's bad.
But also to be fair, even though you give people N releases with both
features available to do the conversion, there are going to be some
significant number of users that simply won't do the conversion until they
are forced to, even though they had 3 releases in which they could have done
it.
Most though will have been more sensible, if the feature decommitment is
promenently makrked in the release notes, and the replacement feature is
also mentioned.
Loren
