On 2009-Aug-26, at 3:54 pm, Darren Duncan wrote:
The question I have is what to do when a single same authority wants to release multiple forks or branches of the same module, each presumably targeting a different use case, and the version numbers for each fork/branch are not supposed to be interrelated.
We could allow arbitrary components in the name; that would give people as much latitude as they want in making up names and splitting them into pieces that are presumably meaningful to a human. Archives like CPAN could either use the whole name as identification (as long as the full thing is unique), or they could pick particular pieces that they will pay attention to (e.g. name + auth + vers) and ignore the rest.
Conventions for other components might evolve over time (e.g. a standard meaning for :branch might become customary); the main use is for documentation and classifying modules so people can search for them, etc. Perl shouldn't care what the name is, long or short, other than having a unique way to identify each module. (We could even have an ID separate from the name, but if the names weren't unique that would be confusing for people too, so I don't see any reason not to keep the long name for that purpose.)
Flagging stable vs. dev releases could be done via a designated component in the long name; or it could be a trait on the module (e.g. is status<beta>, is status<dev>, etc.). Either way, the info is available so you can instruct Perl not to use any alpha modules, or so on.
-David
