On 04/26/2011 11:53 AM, James Westby wrote: > On Thu, 21 Apr 2011 18:23:52 +0100, John Rowland Lenton > <john.len...@canonical.com> wrote: >> * if our projects switch to, say, python 4, then we'd be looking at >> shipping python 4 to all supported ubuntus, including LTS'es. > > I can see why you would want to do this for ease of support, but it's > common for projects to support several versions to avoid this > requirement. > > In addition, making a change like this would likely have effects far > beyond u1, in order to allow u1-on-lts to use a Python version that may > not have been available when it was released.
This is where the /opt/.../UbuntuOne/... install location comes into play for dependencies. Simply using backports means the updated library/tool affects the entire system, which is likely to be a nightmare. Installing a version in /opt, which only one app can find, is safer. My gut reaction is that installs of dependencies in /opt should be very rare, and paved with warnings to the app developers of "You understand that you are *personally* responsible for this version of the library you're installing with your app? And it darn well better not leak out into the rest of the system!" But, it does fit with general Linux development practices in the wider world. >> * it's easy to imagine scenarios where we'd want to ship updated >> versions of rhythmbox, banshee or nautilus (and/or any newer >> application that integrated with our apis). Much more commonly we'd >> want to update plugins to those apps. > > Why would you want to upgrade the apps themselves? > > This seems to be getting away from what I thought was the original > question in the discussion, and in to the more general territory of > wanting to push new stuff in to released versions, and perhaps it is > worthwhile to separate those discussions if possible? This is a cost/benefit question. Chances are it's very expensive to do the integration and maintenance work on non-standard versions of all those apps, and much less expensive to maintain multiple variants of the plugins. But, it's appropriate to consider the problem on both sides as we work our way toward the best solution. >> the thing we need is to have as much feature parity as is possible >> across all the platforms we support, > > This seems to be a core point of contention. Perhaps you could explain > why feature parity across versions of Ubuntu is important to your team. > > As I understood the original question it was how to update client code > to keep it in sync with changes that the server makes. It would be > possible to do that in order to keep old features working and not enable > new features on the old releases. A desire to push new features in to > old releases is valid, but seems to be a different question to me, and > not one that has a lot to do with the code in question being a networked > service client. The key feature of a lightweight client app like this is "the ability to connect to the remote service". It is possible to maintain 5 versions of U1 client that each implement the latest connective features, but depend on only the versions of various libraries/tools available in each supported distribution. That's one for (to take a snapshot today): - Natty, the upcoming release - Maverick, the current release - Karmic, the soon-to-be-removed non-LTS release - Lucid, the current LTS release - Hardy, the soon-to-be-removed LTS release And, it might even be reasonable to ask the U1 team to continue with this rather hefty maintenance burden perpetually, since they happen to be backed by a company that deeply believes in the Ubuntu release cycle. I'm not so sure it's reasonable to ask other developers of other networked client apps to carry similar maintenance burdens. Or at least, we can ask them to, but they're perfectly free to say "No thanks, we just won't bother with an Ubuntu version". Or, they'll do what Dropbox does, and just maintain their own "pirate radio" repository just for their client app, completely avoiding the standards and quality control Ubuntu has in place for repositories. That's not necessarily a bad thing, there's always room for the chaos of evolution. But, the fact that we have multiple projects all stumbling around the same problem also means this is an opportunity to be opinionated, solve the problem once in a way that really fits with Ubuntu, and set an example in U1 for the best way to implement updates for a networked client app on Ubuntu. There are definite advantages to a clean set of thoughtfully developed standards. Allison -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
