Version 0.12.0

Changes

• Make compatible with Elixir releases >= 1.0.0
• Deprecate support for 0.15.1

Version 0.9.0

Changes

• No longer require .conf to be present (or contain any active settings) in order for conform to work.
• If a .conf is not found, but there is a schema present, the schema defaults are used, and any missing config.exs settings are added as a final pass.
• conform.new and conform.configure tasks have been updated, and now prompt when you are about to overwrite either a current .conf, or schema.
• When using conform.effective, conform.configure or using conform via exrm, schema files from all deps are loaded and merged in memory when building the effective configuration. In the case of conform.configure, your .conf will be generated with all the settings for all the apps your project depends on. In the case of conform.effective, the schemas of the deps will be represented in the effective configuration. When building a release with exrm/conform, the merged schema will be deployed with the release.
• conform.effective is now accurate
• lists are now supported as a datatype. They can be specified like datatype: [list: :atom], which in this case would define that setting to be parsed as a list of atoms. The list type should work in combination with all of the other types.
• When using the enum datatype, automatically append the allowed values to the docstring for that setting when generating the .conf. It will show up as something like # Allowed values: foo, bar, baz.
• When generating the .conf, comment out settings which have nil default values. Since nil is rendered as an empty string in the .conf, it broke parsing when no non-whitespace character was present between the = and the next \n.
• Breaking Change: API for translation functions has changed. You must now provide a function which takes either 2 or 3 parameters, depending on whether you want the accumulator parameter. The signature for the new translation functions are fn mapping, value -> and fn mapping, value, acc ->. The accumulator variant is used for cases where you might have multiple mappings which all build into one key in the generated config (your example of Lager logging backends was excellent). Previously the mapping param wasn't present either, this is the schema definition for the setting the translation function is being called for.
• Many bug fixes
• More unit tests
• More ideas (custom datatypes is on my list next)

Version 0.8.5

Changes

• Refactor Schema.load into load! and load variants. load now returns an
  empty schema if it fails.
• Add Schema.coalesce to load and merge all schemas of current project's
  dependencies.
• Add Schema.merge function
• Add more accurate typespecs to Schema
• General refactorings

Version 0.8.3

Changes

• Fixed bug in umbrella projects which caused the conform escript build to fail

Version 0.8.2

Changes

• Update to Elixir v0.14.3
• Fix issue with schema generation ignoring environment