mirror of
https://github.com/lightbend/config.git
synced 2025-01-29 05:30:08 +08:00
another NEWS tweak
This commit is contained in:
parent
3ce0997adc
commit
b88fd55f86
39
NEWS.md
39
NEWS.md
@ -1,37 +1,40 @@
|
|||||||
# 0.NEXT.0: Sometime
|
# 0.4.0: April 12, 2012
|
||||||
|
|
||||||
- the *serialization format has changed* to one that's extensible
|
- this is **rolling toward 1.0** and should be pretty much
|
||||||
and lets the library evolve without breaking serialization all
|
feature-complete.
|
||||||
the time. The new format is also much more compact. However,
|
- the **serialization format has changed** to one that's
|
||||||
this change is incompatible with old serializations, if you
|
extensible and lets the library evolve without breaking
|
||||||
rely on that. The hope is to avoid serialization breakage in
|
serialization all the time. The new format is also much more
|
||||||
the future now that the format is not the default Java one
|
compact. However, this change is incompatible with old
|
||||||
(which was a direct dump of all the implementation details).
|
serializations, if you rely on that. The hope is to avoid
|
||||||
- *serializing an unresolved Config* (one that hasn't had
|
serialization breakage in the future now that the format is not
|
||||||
|
the default Java one (which was a direct dump of all the
|
||||||
|
implementation details).
|
||||||
|
- **serializing an unresolved Config** (one that hasn't had
|
||||||
resolve() called on it) is no longer supported, you will get
|
resolve() called on it) is no longer supported, you will get
|
||||||
NotSerializableException if you try.
|
NotSerializableException if you try.
|
||||||
- ConfigValue.render() now supports ConfigRenderOptions which
|
- ConfigValue.render() now supports ConfigRenderOptions which
|
||||||
means you can get a *no-whitespace no-comments plain JSON
|
means you can get a **no-whitespace no-comments plain JSON
|
||||||
rendering* of a ConfigValue
|
rendering** of a ConfigValue
|
||||||
- supports *self-referential substitutions*, such as
|
- supports **self-referential substitutions**, such as
|
||||||
`path=${path}":/bin"`, by "looking backward" to the previous
|
`path=${path}":/bin"`, by "looking backward" to the previous
|
||||||
value of `path`
|
value of `path`
|
||||||
- supports *concatenating arrays and merging objects within a
|
- supports **concatenating arrays and merging objects within a
|
||||||
single value*. So you can do `path=${path} [ "/bin" ]` for
|
single value**. So you can do `path=${path} [ "/bin" ]` for
|
||||||
example. See README and spec for more details.
|
example. See README and spec for more details.
|
||||||
- supports *array append* `+=` where `path+="/bin"` expands to
|
- supports **array append** `+=` where `path+="/bin"` expands to
|
||||||
`path=${?path} [ "/bin" ]`
|
`path=${?path} [ "/bin" ]`
|
||||||
- supports *specifying type of include* `include
|
- supports **specifying type of include** `include
|
||||||
url("http://example.com/")`, `include file("/my/file.conf")`,
|
url("http://example.com/")`, `include file("/my/file.conf")`,
|
||||||
and `include classpath("whatever")`. This syntax forces
|
and `include classpath("whatever")`. This syntax forces
|
||||||
treatment as URL, file, or classpath resource.
|
treatment as URL, file, or classpath resource.
|
||||||
- supports *including URLs* `include
|
- supports **including URLs** `include
|
||||||
"http://example.com/whatever.conf"` (if an include is a valid
|
"http://example.com/whatever.conf"` (if an include is a valid
|
||||||
URL, it's loaded as such). This is incompatible with prior
|
URL, it's loaded as such). This is incompatible with prior
|
||||||
versions, if you have a filename that is also a valid URL, it
|
versions, if you have a filename that is also a valid URL, it
|
||||||
would have loaded previously but now it will not. Use the
|
would have loaded previously but now it will not. Use the
|
||||||
`include file("")` syntax to force treatment as a file.
|
`include file("")` syntax to force treatment as a file.
|
||||||
- *class loaders are now recursively inherited* through include
|
- **class loaders are now recursively inherited** through include
|
||||||
statements; previously, even if you set a custom class loader
|
statements; previously, even if you set a custom class loader
|
||||||
when parsing a file, it would not be used for parsing a
|
when parsing a file, it would not be used for parsing a
|
||||||
classpath resource included from the file.
|
classpath resource included from the file.
|
||||||
|
Loading…
Reference in New Issue
Block a user