[doap-interest] Stuff I'd like to model

[Shaun McCance]

So here's a list of things that I'd like to be able to model, but can't
with DOAP alone.  I can, of course, always go off and make my own little
extensions, but there's a chance others might be interested in this kind
of stuff too.  Also, working with others reduces the chances of me doing
something stupid.

Branches
I'd like to be able to specify branches of programs, not so much in the
CVS sense (though I'll come to that later), but the "series of related
releases" sense.  So 2.6.0, 2.6.1, and 2.6.2 would all be on the 2.6
branch.  2.6.2 could very well be released after 2.7.0.  This is common
practice.  What's on a branch might vary from project to project (i.e.
bug fixes only, features but no incompatibilities, etc.).  That sort of
information isn't useful to me at the moment, but it might be useful to
others.  Perhaps series is a better term for this.

Aggregate Projects
I'd like to model the GNOME Desktop as a Project.  It doesn't have any
single CVS location, or any single tarball.  Rather, it's a collection
of other projects.  In particular, I'd like to say that the GNOME 2.7.x
series contains the gnome-desktop 2.7.x series, the metacity 2.8.x
series, the yelp 2.6.x series, etc.  Also, that the GNOME 2.7.4 release
contains gnome-desktop 2.7.4, metacity 2.8.1, yelp 2.6.1, etc.

Branches and Tags, CVS Style
It's common practice to tag releases in CVS.  So to get Yelp 2.6.1, you
can check out the yelp module with the tag YELP_2_6_1.  I'd like to give
the CVS tag for any particular doap:Version.  Along the same lines, it's
common for continued development of a branch/series (as above) to happen
on a branch in CVS.  So I'd like to give the CVS branch for continued
development of a series.

Subprojects
This is similar to aggregate projects above.  In fact, they can probably
both be modelled the same way.  It's just a matter of what level the
actual tarball releases are made at.   So gnome-utils contains logview,
gsearchtool, gdictsrc, and gfloppy.  These are sort of projects in their
own right, sometimes even with seperate maintainers, but they don't have
their own CVS module or tarball releases.

Documentation
DOAP provides doap:documenter, which is nice.  But it doesn't provide a
whole lot of information about the documentation itself.  Documentation
can be a project in its own right, and I'd like to model that.  Nautilus
doesn't have its own documentation.  Rather, the documentation for it is
in the GNOME User Guide, which is shipped in gnome-user-docs.  Even for
projects that do ship their own documentation, I'd like to consider the
documentation to be a subproject (as above), and link them.


I have some ideas on how to model some of this information, but I find
that nobody reads emails that are much larger than this.  So I'm just
throwing this out there for comments right now.

--
Shaun