On 01-09-2022 15:18, Maxim Cournoyer wrote: > I had something different on mind; I was thinking of some added field to > our shepherd-service object where the minimal version of Shepherd > required could be specified, e.g. "0.9.1". > > The check could be abstracted in the shepherd-service implementation, > avoiding services writers to handle that by themselves in*each* service > requiring so. > > The benefit would be an improved user experience, and cleaner service > code. Upon reconfiguring a machine not yet equipped with a new enough > Shepherd, Shepherd could print: > > --8<---------------cut here---------------start------------->8--- > The x, y and z services won't be started until the next reboot, as they > require a newer Shepherd version. > --8<---------------cut here---------------end--------------->8--- > > Instead of seeing the new services fail to run without (for the end > user) without any obvious reason. > > Does that make sense? I like this system, it's declarative, simple and doesn't have the defined?-looks-in-(current-module) problem. It also avoids accumulating compatibility fallbacks that probably won't be well-tested. If something like (defined? 'whatever) is desired instead of version checks (though I don't see the value here, see Maxim explanation on different contexts), a similar system based on feature checks could be used instead: (require-exports ; <-- the field   '(((module name) this that ...)     [...])) The (if (defined? ...) preferred compat) pattern could be preserved for the case where a patch author puts in some extra effort to not require reboots on systems where an old shepherd is running, but a simple version check or feature check would be accepted too. Greetings, Maxime.