From continuum-users-return-4111-apmail-maven-continuum-users-archive=maven.apache.org@maven.apache.org Thu Jul 19 06:58:42 2007 Return-Path: Delivered-To: apmail-maven-continuum-users-archive@www.apache.org Received: (qmail 97764 invoked from network); 19 Jul 2007 06:58:41 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 19 Jul 2007 06:58:41 -0000 Received: (qmail 58644 invoked by uid 500); 19 Jul 2007 06:58:21 -0000 Delivered-To: apmail-maven-continuum-users-archive@maven.apache.org Received: (qmail 58402 invoked by uid 500); 19 Jul 2007 06:58:20 -0000 Mailing-List: contact continuum-users-help@maven.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: continuum-users@maven.apache.org Delivered-To: mailing list continuum-users@maven.apache.org Received: (qmail 58391 invoked by uid 99); 19 Jul 2007 06:58:20 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 18 Jul 2007 23:58: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 (herse.apache.org: domain of jesse.mcconnell@gmail.com designates 64.233.184.237 as permitted sender) Received: from [64.233.184.237] (HELO wr-out-0506.google.com) (64.233.184.237) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 18 Jul 2007 23:58:17 -0700 Received: by wr-out-0506.google.com with SMTP id 58so720745wri for ; Wed, 18 Jul 2007 23:57:57 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=axILcR0bEbEnlpfkLzvyOSruqbIhEfxMqai0ibJ95kkU98PRaJYbnIG/Hgji8bRSGEDsIEZOBPu3nkBQpEJ2ufeqL6d5MI9EnIYml2fKaavBlUM6vuSSz19E/HK7urH2vfHHEIzPv283Cz9psriQaCDlnE9w8dcLt6ijhUrHxIk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=QfofyUA9Exjo9PzsZvqaW/BYOlIK3X5cKIIwNMyK+dvmxNx6b19rcmXf9y3VxTUH87lA8M/gXiWwd+HQ34u7K5OyCaxsE3K+bC2rUyCgRPX+ijgKe8kn/d0H/ETszdsYfHEHig+h4CZ2K9vTsl5mJTVDACmaoL5Pw06mW4k8hk0= Received: by 10.142.111.14 with SMTP id j14mr195960wfc.1184828276305; Wed, 18 Jul 2007 23:57:56 -0700 (PDT) Received: by 10.143.10.10 with HTTP; Wed, 18 Jul 2007 23:57:56 -0700 (PDT) Message-ID: Date: Thu, 19 Jul 2007 14:57:56 +0800 From: "Jesse McConnell" To: continuum-users@maven.apache.org Subject: Re: Maven2 release process in Continuum In-Reply-To: <5A0FC4D52198F24F9CC6CFE822269363012A9752@agits-mail03.ag-it.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <5A0FC4D52198F24F9CC6CFE822269363012A9752@agits-mail03.ag-it.com> X-Virus-Checked: Checked by ClamAV on apache.org ok, I am a bit confused by what your actually asking here... but there is no reason in the world you can't use w.x.y.z versioning... On 7/19/07, Johan Iskandar wrote: > I appreciate the reply, > > After yet again thinking about it(may be not hard enough :( ), we don't > need to have version numbers in the sub module poms for reason explained > below. > All we need is for the version number to be at the parent level pom. > And so the sub module poms are tightly coupled to the parent pom and > negating any chances of it being reused by other parent poms. > Why? If we ever need to reuse the behavior of the sub-module pom, we > need to make it a parent pom, and reuse it in a transitive dependent > way. Otherwise it would be a never ending nightmare inside a nightmare.. > > Though we could have sub modules inside a sub module but I don't see why > we really need that, we could just promote the deeper sub module to > become a parent module and again reuse it in a transitive dependent way. > > > From: Arnaud Bailly [mailto:abailly@oqube.com] > > > > Yes, maven enforces an explicit declaration of version in a > > POM. AFAICT, maven does not validate a POM which does not contain a > > version number, so you cannot build it. Maven is rather agnostic about > > version numbering schemes, but understand quit well x.y.x notation > > that is used in version ranges for dependencies management. > > So the build numbering scheme in maven is x.y.x, and not w.x.y.z i.e. it > doesn't differentiate between a build and a bug-fix..? > > Why I think we need to differentiate between build and bug-fix is that > sometimes we want to make refactorings that doesn't necessarily fix a > certain bug (i.e. passes all currently known tests) and doesn't do any > performance enhancements (both can be signified by the y number), but > just to manage codes. > From the user point of view the z is insignificant, but from the > developers point of view it's a big difference and that's why the z > should be there. > > > > > SNAPSHOT is a special qualifier for version that says we are > > building a (surprise !) snapshot development version of a piece of > > software. Snapshots are handled differently from standard versions, in > > that: > > - when you install/deploy a project labelled SNAPSHOT, the artifact > > is actually deployed with a build number and the repository is > > updated to reflect the latest snapshot > Well, if this is done so that the repository doesn't grow too big, I'm > for it though.. > IMHO maven could have just ignored the z number when dealing with user > actions such as getting from/installing to repositories, by only > managing x.y.x format (cuz this is good for transitive dependencies) > > But with simple additions to the config described below we could > accommodate also the w.x.y.z numbering plan > We could define whether the user/developer wants to get up to date at > the build level or just at the bug fix level.. > -If he chooses to get up to date at the bug fix level the current > snapshot mechanism takes action .. > -If he chooses to get up to date at the build level maven will delete > all build prior to and including x.y.x.z builds and replacing it with > the new x.y.x.(z+1) in the repo, and that would still save space... > > So when it comes to code changes and building the changed code maven > knows that it has to change the z number no matter what, and that would > make the automatic builds more meaningful. > > > - you can define different repositories for deploying/downloading > > artifacts. > > > Yes this is one of the good things about maven I like. > > > Best regards, > Johan > Just my 2 cents > > > -- jesse mcconnell jesse.mcconnell@gmail.com