thoughts on breaking backwards compatibility
Alan Sundell
that, in retrospect, were not such good ideas :)
Fixing some of them means making changes in behavior that might break
some people's setups. Here's my short list of stuff I'd like to
break, from the TODO file:
* change behavior of symlinks in SOURCE -- nobody likes the current
behavior, and rsyncd won't let it work as intended anyway. Just copy
them down as symlinks, instead of trying to dereference them within the
repository.
* don't test for -x on scripts, just -e (making non-executable scripts a
fatal error, rather than skipping silently by what is usually a mistake)
* get rid of implicit '-e ssh' with a double-colon in SOURCE. Make people
use --rsh explicitly (maybe add a warning first?)
* replace --cvs-exclude in slack-sync with a better exclude list
[so people can, against my advice :), install .so files and such]
They are all relatively easy to change. The question is whether they
are worth the breakage, and how we should approach this. Should we
break them all at once? Should we do a major version bump, pushing us
to the psychologically-significant "version 1.0"?
Anyone got any thoughts? Is this a terrible idea? Is there something
else we should break while we're at it?
--Alan
David Lowry
> * change behavior of symlinks in SOURCE -- nobody likes the
> current
> behavior, and rsyncd won't let it work as intended anyway.
> Just copy
> them down as symlinks, instead of trying to dereference them
> within the
> repository.
Sounds fabulous to me. I really don't see this as breaking a lot,
since once I figured out that symlinks don't quite work the way you
would expect I quit using them for most things. I imagine most people
did the same thing. I would really like to be able to use symlinks.
> * don't test for -x on scripts, just -e (making non-executable
> scripts a
> fatal error, rather than skipping silently by what is usually
> a mistake)
Like this one, too.
> * get rid of implicit '-e ssh' with a double-colon in SOURCE.
> Make people
> use --rsh explicitly (maybe add a warning first?)
If I remember correctly, this was in response to some trouble I was
having. I think it's probably a good idea. It might also be helpful
to put a short section in the readme describing rsync's behavior with
the various options.
> * replace --cvs-exclude in slack-sync with a better exclude list
> [so people can, against my advice :), install .so files and
> such]
It might be a good idea to make the default exclusion list the same
list as --cvs-exclude. That way, the default behavior stays the same.
If you don't want to exclude anything, you would have to specify an
empty string.
> They are all relatively easy to change. The question is whether they
> are worth the breakage, and how we should approach this. Should we
> break them all at once? Should we do a major version bump, pushing us
> to the psychologically-significant "version 1.0"?
I think these changes are a great idea. However, I agree that the
version number needs a major change. That usually makes it clear that
things might break.
> Anyone got any thoughts? Is this a terrible idea? Is there something
> else we should break while we're at it?
I would say go for it. Of course, you'll probably be doing most of
the work. :-) I'd be glad to test it, though. I think I have a
workaround for each of the changes in my repository (except maybe the
-x one), so I can test it pretty easily.