Return-Path: Delivered-To: apmail-db-derby-dev-archive@www.apache.org Received: (qmail 21268 invoked from network); 11 Feb 2009 19:59:09 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 11 Feb 2009 19:59:09 -0000 Received: (qmail 7677 invoked by uid 500); 11 Feb 2009 19:59:09 -0000 Delivered-To: apmail-db-derby-dev-archive@db.apache.org Received: (qmail 7656 invoked by uid 500); 11 Feb 2009 19:59:09 -0000 Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: Delivered-To: mailing list derby-dev@db.apache.org Received: (qmail 7647 invoked by uid 99); 11 Feb 2009 19:59:09 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 11 Feb 2009 11:59:09 -0800 X-ASF-Spam-Status: No, hits=1.2 required=10.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [66.196.96.94] (HELO smtp121.sbc.mail.re3.yahoo.com) (66.196.96.94) by apache.org (qpsmtpd/0.29) with SMTP; Wed, 11 Feb 2009 19:59:00 +0000 Received: (qmail 88446 invoked from network); 11 Feb 2009 19:58:38 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=sbcglobal.net; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=TW04SPpGkU0GovY0CCBQSXCeVkH4bSTiGMXndecPnlk1++fxkwy0R+jQbyXSoyqDFfktrcB5OzKjqovgDpD7ltkS792OhQ89VxqGIGfN+8b1w/u6L3ecpVCV4qxV+4jzR2Ex3QMfOX0Vz1pdO8Iyx+gCV0NR8OOFqdXsx/iT4rA= ; Received: from unknown (HELO ?9.72.133.61?) (mikem_app@32.97.110.55 with plain) by smtp121.sbc.mail.re3.yahoo.com with SMTP; 11 Feb 2009 19:58:38 -0000 X-YMail-OSG: x4AuEWgVM1ml.FH6QXualZgXN.Mr8vJ_SK32_E9QJbDIEbTxDemVbkju3EwAf5FbdnP45SAOE9VO._WEFLAtF31S3KjwhjCZ0CCruS4SR4DA90sWFGiQSa0KwMT2I19dpKwt9YZvrD.c5WmGcSS3Pw7L X-Yahoo-Newman-Property: ymail-3 Message-ID: <49932DE5.5000406@sbcglobal.net> Date: Wed, 11 Feb 2009 11:58:29 -0800 From: Mike Matrigali User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: derby-dev@db.apache.org Subject: Re: Bumping the fourth digit References: <20090209140957.12A3E23888AF@eris.apache.org> <49919598.7070406@sun.com> <4991C116.3090502@sbcglobal.net> <4991CC43.3050709@sun.com> <4991DAEE.3050106@sbcglobal.net> <4991E23B.9090302@bristowhill.com> <4991E7EC.1090000@sun.com> <4991EA3A.7020509@bristowhill.com> <4991F1BF.3030708@sun.com> <4991FD70.3010407@bristowhill.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org I don't have a problem with allowing 4th digit bumps to any branch by any committer. If someone wanted to bump this with every change I also would not have a problem. As Kathey mentioned this would force a query recompile for every fix which might be safer, rather than force someone to remember it if the fix required the recompile. Even if there is not an official apache release it can help the discussion between developers working on their own builds off the branch to better exactly describe the code they are working. The svn build number included helps with this but some tools and applications just deal with the 4 part version number more naturally. Should we just change the build process to make the 4th digit the build number, ie. the svn number of the last change included in the build? This would give an exact release id for every change and not require manual intervention. Does this break something? I know some process requires one of these numbers to be 0 to force a bets. I don't think we should have JIRA referring to any external releases made by anyone. But it would be nice in JIRA to be able exactly refer to a point in a branch, even if it is not released yet. This way a bug could be logged that say is a regression to the unreleased branch but does not affect changes before X. Currently I just add comments saying the regression happened with change # xxxxx, but it would be better to be able to update the jira affects version field with something exact. For instance this could allow someone how wants to make an official apache release to run a query and decide to make it include changes up to X release id but not everything as there is an outstanding issue.