I believe I started using a 3.x.1 distro package and on the other end a 3.x.5 package if memory serves (this was in April). The minor versions contained tons a

I believe I started using a 3.x.1 distro package and on the other end a 3.x.5 package if memory serves (this was in April). The minor versions contained tons additional new features. If there's something 3.x.y can't do that 3.x.y+1 can't do, the middle number NEEDS to be incremented to signify this change. The promises from the later tail number would not work on the older one. Some things I think would be useful to ease Cfenfgine adoption: * .conf.example files that can be jockeyed around quickly to produce useful working samples within 15 minutes. Specific areas for the above include: installing a file from cfmaster to a host, installing packages using the native package manager, starting services using the native service manager * Reading about promise theory and Cfengine lingo is neat and all but if I'm not convinced of the benefits and have it running in 15 minutes, the install process/doc is flawed. Fixing this will get you much more market share. * All of the above doesn't mean Cfengine can't handle n-th order complexity and diversity. Instead what I am suggesting is to make it very easy to try on in the simplest cases, and wear well with experience and age in tougher environments. * Some simple config enumerator scripts. Run yum, dpkg, etc and get a list of all packages. Output this into a config file that the user can edit and put into use right away. I'll dig through your Cfengine examples some time and see how it's going.