Return-Path: Delivered-To: apmail-geronimo-dev-archive@www.apache.org Received: (qmail 7095 invoked from network); 22 Aug 2006 13:25:15 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 22 Aug 2006 13:25:15 -0000 Received: (qmail 5395 invoked by uid 500); 22 Aug 2006 13:25:14 -0000 Delivered-To: apmail-geronimo-dev-archive@geronimo.apache.org Received: (qmail 5076 invoked by uid 500); 22 Aug 2006 13:25:12 -0000 Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@geronimo.apache.org List-Id: Delivered-To: mailing list dev@geronimo.apache.org Received: (qmail 5065 invoked by uid 99); 22 Aug 2006 13:25:12 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 22 Aug 2006 06:25:12 -0700 X-ASF-Spam-Status: No, hits=0.5 required=10.0 tests=DNS_FROM_RFC_ABUSE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of kevan.miller@gmail.com designates 64.233.184.227 as permitted sender) Received: from [64.233.184.227] (HELO wr-out-0506.google.com) (64.233.184.227) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 22 Aug 2006 06:25:12 -0700 Received: by wr-out-0506.google.com with SMTP id i5so346546wra for ; Tue, 22 Aug 2006 06:24:51 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:mime-version:in-reply-to:references:content-type:message-id:content-transfer-encoding:from:subject:date:to:x-mailer; b=MmM6SB7cSrf7K9SadU3clAeZVc/PHTCR6bg3d7YNB0g8txKCdQ4aBtK79O4ibdcmREW4AaX09H3u0+LyU615wDMMhqXDCLuDWLTcpL6mKzVhqulMg+7k30Z9CRc8RyCZOZE2cCNXgv8HaDDwMKOiy4rRjWcP1AogSi/5C9oiZ1A= Received: by 10.90.115.9 with SMTP id n9mr424859agc; Tue, 22 Aug 2006 06:24:51 -0700 (PDT) Received: from ?192.168.123.134? ( [71.70.213.94]) by mx.gmail.com with ESMTP id 24sm1145602wrl.2006.08.22.06.24.49; Tue, 22 Aug 2006 06:24:50 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <768F19A3-F0D5-4A97-9207-B9FC65B901D4@yahoo.com> References: <7CBF95DA-D858-434C-85EE-DC0915A7E8E2@planet57.com>

<768F19A3-F0D5-4A97-9207-B9FC65B901D4@yahoo.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Kevan Miller Subject: Re: [VOTE] Specs organization, versioning, and releasing Date: Tue, 22 Aug 2006 09:24:55 -0400 To: dev@geronimo.apache.org X-Mailer: Apple Mail (2.752.2) X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N On Aug 22, 2006, at 1:37 AM, David Jencks wrote: > > On Aug 21, 2006, at 9:21 PM, David Blevins wrote: > >> >> On Aug 21, 2006, at 7:13 PM, Kevan Miller wrote: >> >>> As long as we have inter-dependencies between specs (e.g. >>> javamail depends on activation; jaxrpc on saaj, qname, and >>> servlet; and especially geronimo-spec-j2ee depends on >>> everything), I'm not convinced that this really makes things any >>> better... >>> >>> I agree that your plan is better than the previous plan for >>> multiple trunks, but I'm not convinced that either plan is >>> actually making things simpler... >>> >>> If I understand your proposal, tags/geronimo-spec-jaxrpc->> rpcversion>/pom.xml will specify the tagged versions of saaj, >>> qname, and servlet upon which it depends? So, haven't we just >>> split apart the specification of these version dependencies from >>> a single pom.xml into multiple poms? Is this really making things >>> simpler? >> >> That'd be right. I'm not sure how complicated that is, though. >> None of those specs have changed in a year. Can you give an non- >> hypothetical example of something that does change and causes this >> problem that isn't the J2EE uber-jar? Well, the current activation spec is at version 1.1. When that version was bumped from 1.0 (or 1.0.x), you'd have needed to know/ remember to change the poms in the following specs: geronimo-spec- j2ee, geronimo-spec-javamail, geronimo-spec-jaxr, and geronimo-spec- saaj. A question for you, Jason: If someone wants to build our released specs from source, what's the process? > > Maybe I don't understand the proposal, but otherwise IIUC every > time we've found a problem in e.g. the jacc spec we'd need to > release every spec jar, and update all the versions. I guess we do > this with a lot of geronimo jars going e.g. from 1.1 to 1.1.1 but > I think having a lot of identical-contents spec jars would be too > confusing. No, I don't think that's what is happening (at least not in theory), but I've never actually "released" specs. So, I may be mistaken... Current Process for updating jacc 1) Update branches/1_1/pom.xml with new geronimoSpecsVersion and new geronimoSpecsJaccVersion 2) Update jacc spec sources 3) Build all specs 4) Release jacc and uber-jar spec 5) tag branches/1_1 as tags/1.1.x Current Proposed Process 1) Update branches/1_1/geronimo-j2ee/pom.xml with new uber-jar spec version and new jacc spec version 2) Update branches/1_1/geronimo-jacc/pom.xml with new jacc spec version 3) Update jacc spec sources 4) Build jacc and uber-jar (build seperately or together?). 6) Release jacc 7) tag jacc- 8) Release uber-jar 9) tag uber-jar- Single-version Proposed Process 1) Update branches/1_1_/pom.xml with new specs version 2) Update jacc spec sources 3) Build all specs 4) Release all specs 5) tag branches/1_1 as tags/1.1.x I don't see that releasing identical content spec jars are necessarily confusing (as you point out, we essentially do it with every Geronimo release). Less confusing to have only a single version to worry about... What's the latest release 1.1.x geronimo specs? Use that for all of my j2ee 1.4 spec dependencies. Seems simpler than knowing the latest jacc spec is at version x and the latest servlet 2.4 spec is at version y. --kevan