[doap-interest] Dependencies and releases

[Adam R. B. Jack]

> Glad to see there's some interest in getting dependencies and releases
> better subscribed.  It's been a requirement I've been thinking of, along
> with the project/subproject relationships.

Interest in that (as you know Edd) over here also:  http://gump.apache.org.

> I tend to think we need to do quite a bit of thinking about this before
> putting it in.  My strawman model for modelling such things will be the
> metadata present in Debian packages.  As Debian manages to successfully
> package pretty much all open source software in existence, I expect
> their release metadata and dependency modelling to be very near what
> DOAP needs.

I agree Debian is a good example to follow, but (unfortunately) I'm another
who doesn't really know the internals their model. I've been working with
others on Depot Version for a while:

    http://incubator.apache.org/depot/version/
    http://incubator.apache.org/depot/version/jar-hell.html

... it is part of Depot (another, like Maven, like Debian download tool).
The version part if my main interest because I feel that release versioning
has real world issues, and however backwards compatible (or interface
compatible) folks try to be, there are factors outside of the interface
versioning scheme. Meaning, a minor release could introduce a bug that
affects your local site and make that version not compatible with your
environment. In general it might be compatible, but not for you/your needs.
As such, I'd like to see debian-like dependencies and compatibilities be a
collection of statements made by (1) the original developers (2) QA teams
(3) local operators. For example: "X depends on Y", "X requires 1.1 or
above", "X can not use Y 1.2 'cos of blah". Basically, this seems like an
awesome RDF jobs to me.

I'd like to take Depot Version and integrate it with RDF that describes
version compatibilities (along with dependencies) and enable it tools that
introspect the environment and match it to known compatibility rules. In
theory this is simple, in practice it needs some work to allow distributed
management. Again, I think RDF can help here.

> For those considering solutions, please also consider what the simplest
> solution to the problem might be, too.

As you know Edd, Gump's first stab at something is here:

    http://brutus.apache.org/gump/public/
    http://brutus.apache.org/gump/public/gump.rdf

This ignores 'time' (or releases) and just shows now.

> Just a word on process, although I am reluctant to mention it.
> Basically, I reserve the right to control the DOAP schema as I see fit.
> But I hope you'll find me somebody who listens and engages in
> discussions.  Your decision to engage with DOAP really depends on how
> much you trust me as a person.

Seems reasonable for DOAP. RDF ought allow agreement in the main, and cope
with differences of opinion when and if they arise.

regards

Adam