> I don't see why we can't have a versioning scheme for configuration
files, as it seems like a far more productive venture, and would
enable shifts over time.
If I understand correctly, what's proposed is that in htcondor version
N+1 you can turn on some feature X, which makes no sense to version N
(it can't even be parsed).
I don't think a versioning scheme for entire config files helps very
much. You can't expect version N to read an N+1 config file since you
can't predict future changes in syntax. What you could have is
conditional sections like
#if VERSION >= 8.2.0
Funky+new-Syntax
#endif
(of course, that in itself would be a new syntax feature which would
confuse older versions).
But even then, the best you can expect is that version N can ignore
feature X if it is requested in the config. Is that reasonable? In
other words, if the manager configures feature X, is it OK to silently
ignore this? What if that feature is essential for correct behaviour
of the application?
If you have a mixture of nodes running versions N and N+1, it seems to
me that you can:
1. Not make use of feature X
2. Enable feature X on the N+1 nodes only (by pushing out different
configs to those nodes)
3. Upgrade all your nodes to N+1 before enabling feature X
Seems pretty reasonable to me.
Regards,
Brian.
_______________________________________________
HTCondor-users mailing list
To unsubscribe, send a message to htcondor-users-request@xxxxxxxxxxx
with a
subject: Unsubscribe
You can also unsubscribe by visiting
https://lists.cs.wisc.edu/mailman/listinfo/htcondor-users
The archives can be found at:
https://lists.cs.wisc.edu/archive/htcondor-users/
![[Computer Systems Lab]](https://www-auth.cs.wisc.edu/pics/csl_logo.gif){kind=logo}