John Siracusa writes: > * A set of DateTime utility functions
If these are generic DateTime utility functions, not tied into the rest of your suite, then they ought to be released as part of the DateTime namespace (or patched into existing modules in that namespace). But any name in that namespace should be approved by the DateTime mailing list. > Each component depends on some or all of the components above it in > the list. So while some components (e.g., the HTML objects) would be > useful in isolation, actually submitting them to CPAN outside of this > "suite hierarchy" is a bit of a hassle (for the users and the > developer) due to the dependencies. Nonetheless I feel it would be worth doing this for anything completely independent. It may be a little more hassle for you to release a few separate distros rather than one -- but it would be a lot more hassle for a potential user who just wants your DateTime or URI module to have to grab the entire suite. More to the point they are unlikely to be noticed as part of a suite, so your work won't get the attention and usage they deserve, and it's more likely that somebody else will repeat them (only slightly different, and incompatibly) elsewhere. Presumably your suite makes use of some Cpan modules that are maintained by people other than you? I think you should treat any generic 'helper' modules in the same way -- pretend to yourself that they weren't written especially for this project and treat them as Cpan dependencies. > It's my intention to release the entire suite as a "branded" entity > much like Mason, Maypole, or Bricolage, with a unique top-level > namespace to be determined later. (Obviously JCS:: will not do.) That's a good idea. Functional names work best for something like Image::Size or Math::Round -- something that solves a reasonably small and well-defined problem, and which people are likely to search for. But big 'Way of Life' suites probably spread best by word-of-mouth outside Cpan, and having a distinctive and memorable name works well. > but perhaps Mason ... ended up under HTML:: as some sort of > appeasement to the class hierarchy Gods. If so, this was a mistake, > and one I'd not like to repeat. I don't think it was a mistake, in that when I first heard the name HTML::Mason I could guess what the module does from the meanings of the separate words 'HTML' and 'Mason', something that isn't conveyed by just one of them. 'Bricolage' and 'Maypole' are different in that they are just brand names, and putting them in a namespace wouldn't help. > I suspect the guardians of naming are already poo-pooing my intention > to create a new top-level namespace for myself, ... The person who's done the most work in the past few years in helping people with naming is brian d foy on [EMAIL PROTECTED], and I've seen him actively encourage 'brand' names for large projects. Use a branded name for all the parts of your suite that are only useful in the suite. Use generic, meaningful names, for any parts that could be of use outside the suite. Then create a Bundle::WhateverYouCallYourSuite module that includes your suite plus its dependencies (other modules it uses that are in separate distros, whether published by you or other people). > * What should the branded name be? I already have a favorite picked, > but I'm open to guidance (e.g. "no copyrighted names", although I know > that one already :) Whatever you want! But try to pick something that is 'obviously' a branded name, and doesn't sound like it might be a meaningful name. So, for example, in the abstract 'CrossStitch' might work as a branded name. But putting that on Cpan clobbers that namespace from anybody who wants to release lots of modules for doing CrossStitch in Perl. > * Is it okay, or advisable to release a "partial" suite and then fill > in the rest of the components as they are completed? Yes. Release early and release often. That way you get more feedback, and it's easier to accommodate requests and suggestions. > * Is it okay to release modules before the documentation has been > completed? It's better to do it t'other way round -- release modules that have complete-ish docs but some of the documented things haven't been implemented yet! If something doesn't have docs, don't expect people to know what it's for or how to use it. I follow an RSS feed of Cpan uploads, and I investigate anything that sounds interesting. But if it doesn't have any docs then I don't ever bother downloading it just to see what it does. > * These are all version "0.01" at this point. Is that sufficient to > communicate the still-in-development nature of the suite, or should I > simply not release anything unless it's completely documented, at the > very least? I think at least outline docs would be a good idea -- giving the purpose and general idea of things. If that gets anybody interested then it isn't so bad if they have to read the source for the details. (Much better than t'other way round, where you get docs which very carefully explain what each method of some class does but still don't convey any impression of why the class exists or what anybody might want to use it for.) Rather than relying on people spotting the 0.01 I'd also put an explict warning in the docs, at the top of each module, pointing out that it is incomplete, subject to change, and so on. Hope that's of some help, and good look with your suite. Smylers
