coapp-developers team mailing list archive

[Trent Nelson <trent@xxxxxxxxxxxxx>]

On 4/7/2010 12:21 PM, Garrett Serack wrote:
> I like the idea of <vendor>\<app>\<version> too, but one of my
> goals was to have the ability to symlink the current version to a
> predictable well-known-path, and I'd like to use the same pattern
> for all aspects of location determination. (web apps, desktop
> apps, libraries, docs, etc)
>
> I've sketched out some ideas:
>
> The first (under option1), was my original idea-well-known-path
> points to a specific sibling version. This is nice,  predictable,
> and easy to change a path somewhere to switch over to a specific
> version if required, otherwise the 'unversioned' path is
> authoritative. This is similar to common conventions in Linux.


> +---option1
> |   +---openssl         -- symlink to openssl-0.98j
> |   +---openssl-0.98i
> |   +---openssl-0.98j

> +---option3
>     +---openssl         -- symlink to [openssl]\0.98j
>     +---zlib            -- symlink to [zlib]\1.25
>     +---[openssl]
>     |   +---0.98i

This is an interesting discussion point, I think.  I can understand the rationale for having a non-versioned, well-known path pointing to the latest version of something (i.e. openssl symlink to openssl-0.98j).  However, I also think there's a case for projects that would never want to rely on an arbitrary version of a component they depend upon.

Take Python, for instance.  For every Windows release, I can tell you exactly which version of SQLite, OpenSSL, zlib etc that was used, because we version control all our dependencies (http://svn.python.org/view/external/), and are explicit about which versions get used in a given release.

The reason this is important is because that all testing and development is done with everyone using the exact same version of dependencies.  If you happen to build a local copy of a Python release but drop in a different version of SQLite, you end up with a release that's divergent from the 'official' build (at the very least, it'll be untested).

So, I'd argue there's a use case for projects to be explicit about which versions of other components they rely upon for a given release, and that there should be a way for CoApp to support that.

If we move towards building, signing and distributing projects on behalf of their owners, perhaps one of our pre-requisites would be that the project needs to elicit the exact version of their dependencies that they did all their release testing/development against.

Thoughts?

	Trent.