Re: [boost] Library metadata

Subject: Re: [boost] Library metadata
From: Ahmed Charles (acharles_at_[hidden])
Date: 2014-02-23 19:09:58

----------------------------------------
> Date: Sun, 23 Feb 2014 14:55:51 +0000
> From: dnljms_at_[hidden]
> To: boost_at_[hidden]
> Subject: [boost] Library metadata
>
> Hi,
>
> I'm starting to add metadata to modules for updating the website, and
> hopefully other uses in the future. I added the metadata to
> Boost.Unordered and Boost.Functional to give you an idea of what this
> will look like:
>
> https://github.com/boostorg/functional/tree/develop/meta
> https://github.com/boostorg/unordered/tree/develop/meta
>
> You can see several libraries listed in the Boost.Functional file.
> I'll write some documentation soon, but it should be fairly easy to
> understand. I basically took what was in the website library list and
> split it up into modules. Quick summary of the fields:
>
> key - Used to be the website to identify each library. Don't change
> it, or the website will think it's a new library.
> boost-version - The version in which the library was released.
> name - The name of the library.
> authors - The authors of the library - will probably add a
> 'maintainers' field later.
> description - Library description - this is used in the library list,
> so keep it short.
> std-proposal - Is the library proposed for the standard.
> std-tr1 - Is the library part of TR1.
> category - The categories the library belongs to. one element for each
> category. The documentation will include a list of available
> categories.
> documentation - Path to the documentation.
>
> The documentation field is optional. If it isn't included, it'll use
> the default path: /libs/module-name/. If it is included, relative
> paths are resolved relative to the module directory, absolute paths
> from boost root - although I'd suggest you always use a path within
> the module, and if there's only a single library in a module, use the
> default path.
>
> This isn't the final format - I think the standards status fields
> could do with an overhaul to support C++11 etc. You also don't need to
> write the initial files yourself, I'll generate them and create pull
> requests once this is settled.
>
> Let me know what you think.


+1 on adding a maintainers field.

On another note, did you consider JSON as a viable format or is there a strong reason to go with XML?