RE: [Yaml-core] Release Planning

[Oren Ben-K. <or...@ri...>]

Clark C . Evans [mailto:cc...@cl...] wrote:
> schedule:
>  - 
>   name: Working Draft Call For Implementations
>   from: now
>   till: August 31st

Seems reasonable. BTW, I started working again on my pull-based parser...

>   issues: 
>     - Does block escaping "return" (Oren votes no)

Quite.

>     - Do we keep (nil) and family (Brian votes no)

There Is More Than One Way To Do It! :-)

>     - >
>       I'm thinking of cleaning up the XML paper
>       and including it as an appendix to the 
>       specification for two reasons: (a) to provide
>       a standard YAML to XML binding for those who
>       want YAML but are required to use XML, (b) give
>       further clarification regarding the information
>       model (a non-normative equivalence).

I think that a document relating XML and YAML is useful, but not as an
appendix. It should just be a separate document. Likewise a document showing
a detailed example of how a sample in-memory data structure is
(de)serialized to YAML (going through the various information models). I
think that adding them into the spec (as appendixes or whatever) needlessly
complicates matters. Besides, the spec is already quite large.

>  -
>   name: Working Draft Last Call
>   from: September 1st
>   till: December 31st

OK.

>  - 
>   name: Proposed Specification
>   from: January 1st
>   till: May 10th
>  -
>   name: Final Specification
>   from: May 11th

If "Proposed Specification" can't change other than bug fixes, isn't 5
months rather a long time to do that? Besides, assuming there's no (major)
changes during the last calls period, we'd have 3 months to look for bugs
anyway. How about we shorten the "look for bugs" period to, say, two months?

Have fun,

	Oren Ben-Kiki