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. _______________________________________________ Mailing list: https://launchpad.net/~coapp-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~coapp-developers More help : https://help.launchpad.net/ListHelp
