Return-Path: Delivered-To: apmail-repository-archive@www.apache.org Received: (qmail 92872 invoked from network); 10 Nov 2003 20:08:25 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 10 Nov 2003 20:08:25 -0000 Received: (qmail 25706 invoked by uid 500); 10 Nov 2003 20:08:14 -0000 Delivered-To: apmail-repository-archive@apache.org Received: (qmail 25672 invoked by uid 500); 10 Nov 2003 20:08:14 -0000 Mailing-List: contact repository-help@apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: repository@apache.org Delivered-To: mailing list repository@apache.org Received: (qmail 25659 invoked from network); 10 Nov 2003 20:08:14 -0000 Received: from unknown (HELO mx1.try.sybase.com) (130.214.10.19) by daedalus.apache.org with SMTP; 10 Nov 2003 20:08:14 -0000 Received: from mail.try.sybase.com (mail.try.sybase.com [130.214.10.18]) by mx1.try.sybase.com (8.11.6/8.11.0) with ESMTP id hAAJ2I231520 for ; Mon, 10 Nov 2003 12:02:18 -0700 Received: from tsws1 ([10.22.120.83]) by mail.try.sybase.com (8.11.6/8.11.6) with SMTP id hAAJtak07573 for ; Mon, 10 Nov 2003 12:55:37 -0700 Message-ID: <0e8e01c3a7c6$66b9ed50$8f8b1f43@tsws1> From: "Adam R. B. Jack" To: References: Subject: Re: Processing Versions Date: Mon, 10 Nov 2003 13:08:18 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N > So it will be our problem if we would like > to consider any constrains for version names (which IMHO are no realistic > in short term (if ever) even inside ASF) . > That's why I strongly believe that any discussion about artifact versioning > simply should not take place. You don't want to slow down repository in order to attemtp to debate/define some likely insoluble attribute. I respect that, and complete agree. Just like other artifact metadata, we are agreeing to defer on them. I am making the point that without understanding the version (to some extent) we will not be able to have intelligent clients that can do anything 'intelligent' without metadata. We can't automatically clean up older copies (we can't trust a timestamp), we can't selected "the best", we can't order, etc. We've agreed that we ought not inhibit apache teams/tools extending the repository with metadata. A live and let live approach. All that I'm asking is that we don't limit tools from benefits just because we don't wish to define them. > And we should assume that > version = pchar* Sorry, I don't have the definition of pchar to hand. Does it includes '-'? Does it include period and the following '.jar'? I'm not so much trying to define the version namespace, but allow us to parse the URIs without ambiguity. I think we need to take Tim's proposal as a good starting place and dissect each part until we believe it to be tight. Just like Nick has started with version location: http://nagoya.apache.org/wiki/apachewiki.cgi?ASFRepository/ToDo I feel we need to do this for group, for type, and so forth. I know it is tedious, but (as I said before, sorry to repeat) this is probably *all* this repository@ workgroup ought focus on/produce. regards, Adam