Uploaded image for project: 'CFEngine Community'
  1. CFEngine Community
  2. CFE-1889

Future proof syntax feature



    • Type: Task
    • Status: Done
    • Priority: Medium
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 3.7.0
    • Component/s: Parsing
    • Labels:


      The idea is to have a way to write syntax which is new for a given version of CFEngine, and still have that file parse correctly on older versions. Today's situation is that such syntax will cause a parse error on older versions and prevent execution.

      The current proposal:

      bundle agent main
      create => "true";

      @if version_after(3.7)
      attribute => "value";

      The only tweakable text in that example is "3.7", which can be any "x.x" number.

      There are several reasons for using the "version_after" construct:

      1. Language syntax should always be backwards compatible, so there is never a need to specify "@version_before(3.7)@".
      2. It limits the syntax in scope, so that we don't run into problems where the future proof syntax itself is incompatible between versions.
      3. It allows a safe deprecation path in the future: If we decide that we want to deprecate and eventually remove this syntax it will be safe to do so after enough feature releases, because:
        1. If we stop providing versions after a certain point, say 3.10, then no policy will ever have a higher number than "@version_before(3.10)@". If they tried to, it would be a parse error (I assume that future proofing the syntax is accomplished by a different feature at this point, for example free form syntax).
        2. Removing such sections are guaranteed to be a no-op for all versions including and following 3.10, since the block was always active in those versions.
        3. If we remove the "if/endif" support in 3.13, we guarantee that all versions since 3.10 will work.
        4. The only work required for the customer is to actually remove the "if/endif" parts, but this will be easy because of point 1, and side effect free.


          Issue Links



              • Assignee:
                a10040 Kristian Amlie
                a10040 Kristian Amlie
              • Votes:
                0 Vote for this issue
                5 Start watching this issue


                • Created:

                  Summary Panel