tags instead of categories (was Re: [SVN] New info.plist keys for description etc.)

[Allan Odgaard]

On 18. Feb 2007, at 00:25, Benoit Gagnon wrote:

> What I'm favoring, globally, is to completely separate the bundles
> from the application. Updating TM would not include new bundles.
> Downloading it the first time either, but instead would pop the bundle
> manager to ask for bundles to download.

Yes, this is a long-time goal, as stated earlier in this thread.  
Though there will be some bundles included; imagine the user is in an  
environment without internet connection or cancels the initial bundle  
manager (so a few bundles, like Text & Source, will be enabled by  
default).

> It's true that svn log will give me detailed changes to the bundles.
> But it won't tell me easily what's new from the previous version I had
> (I'd need to note down the revision I'm at first). Version control
> logs are also rarely effective from an end-user perspective. I don't
> see many applications dumping me their SCM log as "release notes"
> whenever I update it.

We have the tagged entries for the release notes that goes out to the  
user. Are you suggesting some third way to handle changes?

I.e. we currently have a) svn log for people who want to know  
everything, b) the tagged entries for people who only want to know  
what we deem important.

Ideally we would have c) changes that the user deem important, but  
this is what we try to do with b ;)

> As for the support directory, I don't see why it couldn't be a  
> bundle itself.

Are you talking about a TextMate bundle? I can’t see how it could be  
made into such.

The support directory contains stuff relied on by other bundles. We  
could version the support directory (in fact we already do), and  
bundles could require certain versions, there already is support for  
doing that, but no-one uses it, because it is tedious and not working  
in practice, for example a change in the support folder may be  
required for a single command in a bundle, so that command should now  
require e.g. r6124, but another change in the support directory may  
require a fix in a bundle, so now that bundle (in the unfixed  
condition) will require a version prior to r6125 -- effectively  
meaning that often, if you don’t have the latest of everything, you  
won’t satisfy the dependencies (and it would be a lot of overhead to  
express these dependencies, just so a few users can select to run  
with old bundles).

> Sorry for opposing some of you guys in this discussion; I'm really
> excited about this new bundle system and I want to make sure my ideas
> are dropped in the pre-prod pool :)

Ideally I think what you want would be nice, it’s just impractical  
and not worth it, i.e. many technical hurdles, lots of manual work  
finding out which min/max versions of something a bundle command  
requires, and few would intentionally upgrade only subsets of the TM  
environment.