On Mar 15, 2012, at 09:52, no-re...@cfengine.com wrote:
> I have been thinking about the issue of metadata for bundles, e.g. such as
> author and version, and have been through a number of alternatives in my head,
> The problem I have with each of them is that they either change syntax in an
> ad hoc way to something that is not a natural promise, or they separate the
> metadata into a separate body. Neither of these seems acceptable.
>
> My best answer, which requires no immediate feature implementation is to do
> this by best practices, using reserved variables.
>
> vars:
>
> "bundle_author" string => "kermit";
> "bundle_version" string => "1.2.3 frog legs";
>
> These are private and can then be used as variables, and examined using
> functions $(bundle.bundle_version) for validation.
>
> Comments?
Hi Mark,
I welcome that you have thought about versioning of bundles themselves! The
"version"
control promise is too broad to version a CFengine installation, especially
when you
import promises from several master servers: the control promise comes from
server A
and has version 42, and it imports bundles from server B which in its control
promise
has version 463. The client spits an error in a bundle from server B but prints
42 as
version. That is confusing and having per bundle versions would decrease that
kind
of confusion.
The problem I have with introducing reserved variables, is that there will
always
be -somebody- who actually uses them in an existing promise, and no matter how
well you have thought about the consequences, the introduction of reserved
variables
will break things in ways you never envisioned.
In my opinion it would be better to introduce an optional "metadata" promise
type.
In that way you wouldn't break existing installations. Something like:
metadata:
author => "kermit";
email => "ker...@muppetshow.example.com";
version => "42";
purpose => "Make sure Miss Piggy doesn't get angry";
comment => "Please don't let her read this!";
Once you have introduced that in the language you can start to use it. You can
start
with printing the version in error messages, but a nice feature would be to be
able
to require certain known good versions of bundles, which requires a way to
compare
version numbers. In the open source world we all love long and complicated
version
numbers (v1.2.3-pre4-beta5), but that makes it hard to compare versions: if
"better
than '1.2.3 frog legs'" is required, how would you tell the system that
'1.2.3-rc1'
satisfies that requirement? I think the only way to solve that is to require
that
the version metadata promise is either something numerical (int, float) which
makes
comparison easy, or you make it a string and use strcmp() to compare versions.
Both ways have their pros and cons, but from the principle of least surprise a
numerical version has the least amount of corner cases.
Food for thought, hope this helps :-)
Regards,
Erik
--
Erik Mouw -- erik.m...@snow.nl
Snow B.V. -- http://snow.nl/
_______________________________________________
Help-cfengine mailing list
Help-cfengine@cfengine.org
https://cfengine.org/mailman/listinfo/help-cfengine
