Only one more week to submit CPAN Meta Spec proposals

On August 26, I issued a Call for Proposals for the CPAN Meta Spec. It is now one week away from the deadline for submission. There are over twenty-five proposals already (see below) as well as numerous other brainstorming ideas that haven't been fleshed out into full proposals yet.

There is still time to help out with this effort. Please see the rest of this article for deadlines and how to participate.

Timeline

Over the next couple months, a working group of Perl/CPAN toolchain developers, maintainers, packagers and indexers will review the proposals and finalize the new CPAN Meta Spec.

• The Call for Proposals will close on Oct. 1, 2009
• The working group will post proposals on the cpan-workers mailing list
  for public discussion
• Public discussion will close on Nov. 1, 2009
• The working group will reach consensus on proposals to adopt or reject
  and release a new CPAN META Spec no later than Dec. 1, 2009

How to participate

Check out the CPAN Meta Spec proposals page and add new proposals or just refine the proposals that are already there.

Next, join the cpan-workers mailing list by emailing cpan-workers-subscribe@perl.org. List archives are available at http://www.mail-archive.com/cpan-workers@perl.org/. Expect much more traffic in November as we refine and triage the proposals.

Current list of proposals

• 1 Formatting and schema
  • 1.1 Update the YAML version declaration
  • 1.2 Formally switch to "YAML Tiny"
  • 1.3 Deprecate YAML Tiny dialect for JSON
  • 1.4 Formalize allowed version number formats
  • 1.5 Schema
  • 1.6 Data structures, not YAML
• 2 Prerequisites
  • 2.1 Enhance granularity of prerequisites
  • 2.2 Extensibly Group Prereqs
  • 2.3 Clarify intent of 'recommends' and add 'suggests'
  • 2.4 Add a free-text prerequisite field
  • 2.5 OS/arch/platform-specific requirements
  • 2.6 Allow Sequences (Arrays) for Prereqs
  • 2.7 Add a post_depends set
  • 2.8 Prerequisites should be mutually exclusive
  • 2.9 Add development_requires
• 3 Change/clarify existing fields
  • 3.1 Better formalization of license field
  • 3.2 Make dynamic_config mandatory
  • 3.3 Make repository resource a hash
  • 3.4 Make bugtracker resource a hash
  • 3.5 Formalize optional_features
  • 3.6 Clarify author field
• 4 Add new fields
  • 4.1 Have a "development version" flag
  • 4.2 Add a "release_status" field
  • 4.3 Controlling test suite runs
  • 4.4 Specify a DLSIP resource
• 5 Other (not yet classified)
  • 5.1 steal from other package meta specs
  • 5.2 Install Meta files and make them queryable