From ivy-user-return-1458-apmail-incubator-ivy-user-archive=incubator.apache.org@incubator.apache.org Wed Aug 15 20:50:23 2007 Return-Path: Delivered-To: apmail-incubator-ivy-user-archive@locus.apache.org Received: (qmail 17719 invoked from network); 15 Aug 2007 20:50:23 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 15 Aug 2007 20:50:23 -0000 Received: (qmail 57100 invoked by uid 500); 15 Aug 2007 20:50:20 -0000 Delivered-To: apmail-incubator-ivy-user-archive@incubator.apache.org Received: (qmail 57078 invoked by uid 500); 15 Aug 2007 20:50:20 -0000 Mailing-List: contact ivy-user-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: ivy-user@incubator.apache.org Delivered-To: mailing list ivy-user@incubator.apache.org Received: (qmail 57069 invoked by uid 99); 15 Aug 2007 20:50:20 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 15 Aug 2007 13:50:20 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of sbailliez@gmail.com designates 66.249.92.174 as permitted sender) Received: from [66.249.92.174] (HELO ug-out-1314.google.com) (66.249.92.174) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 15 Aug 2007 20:50:18 +0000 Received: by ug-out-1314.google.com with SMTP id t30so283625ugc for ; Wed, 15 Aug 2007 13:49:56 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=MSNS8tgnGSy1GW7+uHTNQ3SlV9woaKiiz8G+VdS9chogXeQ7POCbq7yI/5q0gXYzWZfD9MZ7KKm/x/r8gJEzy2a39tVXNTfhuWWa710IL68Ai/HWsxBbJU0ZlK6stznM5AXtNYlKRXRuYeonT2Nj7FnhdAGZkHwmduDkEq8fWVc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=BOElHVA0WJ7R98ifxxYVFluJtflcjReZgjpza4uy5Frjm1loOshHogIVqFdzANwrXke+H4HEgqC0w57vv0I0Ga6pE5H825NkApjduiHJ3RUC9aEDTLRY0NFR5jaWsOQLOnKOPAQVuPvRFEepdvqbzos57gSwyk5CvDceYTUjjho= Received: by 10.67.20.11 with SMTP id x11mr1681894ugi.1187210996444; Wed, 15 Aug 2007 13:49:56 -0700 (PDT) Received: from ?192.168.1.123? ( [212.64.5.16]) by mx.google.com with ESMTPS id d26sm299245nfh.2007.08.15.13.49.51 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 15 Aug 2007 13:49:52 -0700 (PDT) Message-ID: <46C366E4.6080703@gmail.com> Date: Wed, 15 Aug 2007 22:49:40 +0200 From: Stephane Bailliez User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: ivy-user@incubator.apache.org Subject: Re: Best Practices for Version Convergence References: <72A37CC27F2CAB44BD13E814D2F4FE0E03234F6B@mercmbx08.na.sas.com> In-Reply-To: <72A37CC27F2CAB44BD13E814D2F4FE0E03234F6B@mercmbx08.na.sas.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Nascif Abousalh-Neto wrote: > One of the features that attracted me to Ivy was the possibility to > switch between dynamic and fixed versions. While dynamic versions can > help you to keep your code always integrated with the latest and > greatest from your dependencies (specially if backed up by a Continuous > Integration server), a static version can protect you from a buggy new > version and allow you some stability to develop a new feature while your > dependency is churning. > > But I got worried after a conversation with a friend from a large > company, which told me that they gave up on using static versions > because they would never converge. Complex products typically have many > "diamond-shape" subgraphs embedded in their dependency graphs, which > creates lateral dependencies that are hard if not impossible to catch > locally. Even if you can detect them early by using tools that can > pinpoint the affected areas in the dependency graph, they are still hard > to solve if they cross team boundaries. > [...] > Has anybody working on a similar scenario faced this issue? Any advise > or suggestion? > There is not one size fit all answer for this I'm afraid. It depends a lot on the team process. They type of products you are building internally and if all these products obey the same type of deadline and focus, team experience, etc... I have always found that the barrier to any dependency management is not the tools in any way or any technical issue but it is mostly a human process. You will spend a full year of frustration of people not listening and continuously doing weird things and complexify the builds and processes in amazing way. I have experienced that several times and it is _always_ the same story as frustrating as this is. (and large software companies doing IT work are not any better, I have seen very very very very silly things in 150+ developer projects) It all depends as well how much the team in question has had to product development in comparison to short-term IT-type development. The approach and mindset will be very different between all those people. Sometimes you will have no choice than to let people do the wrong thing until they are knee deep in a terrible mess and willing to accept the obvious. Human is the most painful part to change management. -- stephane