[SVN] New info.plist keys for description etc.

Allan Odgaard throw-away-1 at macromates.com
Tue Feb 13 21:56:19 UTC 2007


Bundles have long needed some extra metadata to improve its  
presentation in aggregated contexts.

Here are what I suggest we add to the `info.plist`:

* Category
* Dependencies
* Description
* Maintainer
* Technology URL
* Status

What follows are some comments about each of these fields.

Please don’t hesitate to comment on this proposal.


# Category

Eventually I want 99% of the bundles disabled by default, and have  
the user start out by picking what he needs. Since there are >100  
bundles, there needs to be some organization.

The categories I had in mind was:

1. Markup / Prose
2. Programming
3. Framework
4. Build System
5. SCM System
6. Utility / Other

In addition I also think it would be useful if each bundle had an  
embedded thumbnail to be used for such display purposes. E.g. the  
Ruby on Rails bundle would embed the RoR logo etc.  We probably do  
not need a key to specify the path of such resource but instead could  
just always require it was there as `Thumbnail.«type»`.


# Dependencies

An array of bundles that this one builds on. For example Ruby on  
Rails requires the Ruby bundle. This is useful when installing a  
bundle via a wizard.


# Maintainer

This is the maintainer of the bundle in the venerable `full name  
<email>` format. Likely we should ROT13 encode this field, as the  
`info.plist` will often be available over http.

I deliberately avoided the use of author, since many bundles receive  
work from many contributors, and so if this was `author`, the list  
would probably be monotonically increasing.

I think a bundle should only have one maintainer. True in practice we  
have bundles maintained by several people, but the main purpose of  
this field is to list someone the user can contact about the bundle.  
If there are two maintainers, listing both will just “confuse” the  
user as to who he should write, and there is only a 50% chance he  
will actually write the one responsible for the thing he writes about.

Comments on this one? We could always make it an array, so we at  
least have the option, but lets keep the name of the key in singular  
form.


# Description:

The oft requested description. I second the suggestion (from the  
thread started by Sebastian Gräßl) that this should be Markdown. We  
do need a semi-rich description language to be able to embed hyper  
links etc.


# Technology URL

A better name for this key is definitely required.

This should link to the technology that the bundle adds support for.  
E.g. the svn bundle would link to http://subversion.tigris.org/, the  
Markdown bundle to http://daringfireball.net/projects/markdown/, etc.

Might be a little ambiguous with things like the SQL bundle.

Sure the technology link could easily be in the description, but by  
having it as a separate key we ensure that bundle authors do not  
forget to fill out this info. It also allows a uniform presentation  
of this link, which might benefit the user when skimming over bundles.


# Status

The status of the bundle should probably be something like stable /  
unstable. Not entirely sure, especially since we do not branch  
development and release bundles.





More information about the textmate-dev mailing list