From continuum-dev-return-5138-apmail-maven-continuum-dev-archive=maven.apache.org@maven.apache.org Thu Aug 24 04:31:04 2006 Return-Path: Delivered-To: apmail-maven-continuum-dev-archive@www.apache.org Received: (qmail 51333 invoked from network); 24 Aug 2006 04:31:04 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 24 Aug 2006 04:31:04 -0000 Received: (qmail 77182 invoked by uid 500); 24 Aug 2006 04:31:03 -0000 Delivered-To: apmail-maven-continuum-dev-archive@maven.apache.org Received: (qmail 77151 invoked by uid 500); 24 Aug 2006 04:31:03 -0000 Mailing-List: contact continuum-dev-help@maven.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: continuum-dev@maven.apache.org Delivered-To: mailing list continuum-dev@maven.apache.org Received: (qmail 77140 invoked by uid 99); 24 Aug 2006 04:31:03 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 23 Aug 2006 21:31:03 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: local policy) Received: from [64.14.253.182] (HELO mail.exist.com) (64.14.253.182) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 23 Aug 2006 21:31:02 -0700 Received: from [125.212.117.86] ([125.212.117.86]) (authenticated bits=0) by mail.exist.com (8.12.11/8.12.11) with ESMTP id k7O4TZ5Y004729 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 23 Aug 2006 21:29:39 -0700 Message-ID: <44ED2B71.6010900@exist.com> Date: Thu, 24 Aug 2006 12:30:41 +0800 From: Edwin Punzalan Organization: Exist Software Engineering User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: continuum-dev@maven.apache.org Subject: Re: Release Management for Maven/Continuum References: <5947006.post@talk.nabble.com> <30A013F9-9788-4C4A-A99D-AB66BC6A73C0@apache.org> In-Reply-To: <30A013F9-9788-4C4A-A99D-AB66BC6A73C0@apache.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N I'll be updating the white-site... Please see my inline comments below Brett Porter wrote: > Feedback: > - I'd rather Release be equivalent to "build now" (ie, we might need > an icon for it), so added to the right-hand tasks per project, and > added to the individual project page as a button. > > - I don't think this should operate on a group. It doesn't necessarily > equate to a multi-module project, so instead I'd just go project by > project. If they hit the parent then they get to release a bunch at > once, as is the case in maven > Above is what we've talked about in IRC and its fine with me. Makes things simpler, too. > - I like the summary page that lists out all the defaults, however > instead of an "edit" link, how about making the whole thing a form > with defaults that gets submitted? The summary page shows only a few of the release parameters. So the "Edit" link is there to direct the user to the more detailed release configuration page. But since we'll be releasing projects one at a time, I guess I can incorporate what you mean into the new white-site. > > - I don't think we should have checkboxes on which modules to release, > as that doesn't really correspond to what we have now, and likewise > the "from parent" checkbox wouldn't be relevant I get what you mean, so ok. > > - there will be more elements to configure - we should get them into > the interface now I'll try to put them all in the next white-site > > - on prepare finished, it should look like the build result page. We > are only building one thing if you agree with the above > > - likewise for perform > > - as Jason said, prep and perform should be separate. I'm not sure of > the best way to do this - perhaps hitting the release button presents > the following options: > * prepare release from current code > * perform release from (list of previously prepared releases that > haven't been performed) > * perform release from SCM tag ok, so this means continuum should remember prepared releases. Should there be a separate release working directory for this? Because a prepared release may get lost after a scheduled build.