Now is the time, I guess, to add a meta-proposal of sorts. I had pondered doing this earlier, but felt it was out of place compared to the other elements.
I'd like to propose that all changes to the META.yml be fully and completely defined, without resort to the behaviour of external code. That is to say, all cases where a value must be in some enum should describe the full list, instead of reaching for "Any value that Some::Module allows". This is the kind of logic that got us "margins behave like Word 95" in the OOXML specification, and it had no place in a formal specification. Likewise, I'd like to see all additions address BOTH the issue of required downstream behaviour from both the CPAN client and the binary packagers, and the requirements for back-compatibility. That will allow us to actually implement these changes on branches of the toolchain modules BEFORE we release the spec changes. One of the most common reasons for failure in the specification process is implementing wishlist changes to a specification that nobody has ever implemented before (witness CORBA et al). I'd like to see all these changes working for real before we lock in what might be a serious failure (as we've seen with a number of existing features in META.yml which were specified before anyone had ever implemented them). Adam K On Tue, Nov 3, 2009 at 9:42 AM, David Golden <xda...@gmail.com> wrote: > The public discussion period for CPAN Meta Spec Proposals is now closed. I > would like thank everyone who contributed proposals, feedback and patches. > We received 34 proposals, which resulted in over 340 discussion emails from 23 > people. > > Of the 34 proposals, 18 had some degree of consensus and at least a rough > draft patch (or git branch) to use to revise the spec. Two more proposals > had patches but one was controversial and the other clarifies an existing > field in lieu of adopting the proposal. > > All of these will now be merged into a single draft 2.0 META spec and > circulated to the working group for review and refinement. The working group > will finalize the new specification by December 1, at which point it will be > released as final and work will begin to implement the spec in the CPAN > toolchain and other downstream consumers. > > Again, thank you to all who contributed. A summary of the results is > provided below. All of the proposed patches are also available in branches > at the github repository: http://github.com/dagolden/cpan-meta-spec > > Sincerely, > David Golden > > #---------------------# > SUMMARY OF RESULTS > #---------------------# > > Some consensus and patch written: > > 02. Formally switch to "YAML Tiny" [patch by Ricardo Signes] > 03. Deprecate YAML Tiny dialect for JSON [patch by Ricardo Signes] > 04. Formalize allowed version number formats [patch by David Golden] > 06. Data structures [examples in spec], not YAML [patch by Ricardo Signes] > 07. Enhance granularity of prerequisites [patch by Ricardo Signes and > David Golden] > 08. Extensibly Group Prereqs [patch by Ricardo Signes] > 09. Clarify intent of 'recommends' and add 'suggests' [patch by David Golden] > 12. Allow Sequences (Arrays) for Prereqs [patch by David Golden] > 15. Add development_requires [patch by David Golden] > 17. Better formalization of license field [patch by David Golden] > 18. Make dynamic_config mandatory [patch by David Golden] > 19. Make repository resource a hash [patch by Ricardo Signes] > 20. Make bugtracker resource a hash [patch by Ricrado Signes] > 21. Formalize optional_features [patch by David Golden] > 22. Clarify author field [patch by Lars Dɪᴇᴄᴋᴏᴡ 迪拉斯] > 24. Add a "release_status" field [patch by David Golden] > 27. Long description [patch by David Golden] > 34. Formally reserve keys for private 'in-house' use [patch by David Golden] > > Controversial, but patch written: > > 29. Language [patch by Ricardo Signes] > > Not adopted, but patch written to clarify existing, similar field: > > 30. Trove-Like Categories > > No consensus or consensus opposes or duplicative or other reasons for > not including in 2.0: > > 01. Update the YAML version declaration > 05. Schema > 10. Add a free-text prerequisite field > 11. OS/arch/platform-specific requirements > 13. Add a post_depends set > 14. Prerequisites should be mutually exclusive > 16. Binary Package Dependencies > 23. Have a "development version" flag > 25. Controlling test suite runs > 26. Specify a DLSIP resource > 28. Short description > 31. Version changes > 32. Steal from other package meta specs > 33. Install Meta files and make them queryable >
