Re: Processing Versions
Michal Maczka wrote: I wrote: ".. repository [...] won't be limited to projects hosted at ASF." In requirement list I can see: "ASF Repository shall not Host any artifact in violation of a license, or IPR. " And if anything was discussed before - above statement reflects well the temporary decision which was made and all the limitation which were considered. (temporary in that sense that anything is not written on the stone) Those are just my assertions. No one has objected so I suppose they are still the "Requirements." smime.p7s Description: S/MIME Cryptographic Signature
Re: Processing Versions
> 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
RE: Processing Versions
> -Original Message- > From: Adam R. B. Jack [mailto:[EMAIL PROTECTED] > Sent: Monday, November 10, 2003 5:11 PM > To: [EMAIL PROTECTED] > Subject: Re: Processing Versions > > > > [...] and repository > > possibly won't be limited to project hosted at ASF. > > This is why we need the Wiki, the e-mail archives are too hard to comsume. > It was agreed a while ago that this is for Apache software, we > aren't trying > to solve this problem for everybody else. We need to stop going back over > closed discussions to make simple progress. > I wrote: ".. repository [...] won't be limited to projects hosted at ASF." In requirement list I can see: "ASF Repository shall not Host any artifact in violation of a license, or IPR. " And if anything was discussed before - above statement reflects well the temporary decision which was made and all the limitation which were considered. (temporary in that sense that anything is not written on the stone) So I don't see anything which mentions that artifacts "produced" outside ASF will be not hosted in ASF repository. It's just "NO" to "no kosher" artifacts (in sense of license) in that repository. 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. And we should assume that version = pchar* Michal
Re: Processing Versions
> [...] and repository > possibly won't be limited to project hosted at ASF. This is why we need the Wiki, the e-mail archives are too hard to comsume. It was agreed a while ago that this is for Apache software, we aren't trying to solve this problem for everybody else. We need to stop going back over closed discussions to make simple progress. regards Adam
Re: Processing Versions
That sounds more like a 20/80 rule, i.e. you can't for some -- so don't bother for all. ;-) Who is to say we couldn't get some sort of agreement amongst apache software? Sure somebody can try to find this agreement on one fine day. But this is completly ortogonal to the repository and repository possibly won't be limited to project hosted at ASF. So I am proposing to close this this issue with resolution "WON'T FIX". Let's take this to Wiki [I'll figure out a way]. I am almost sure that with WIKI we will have much more chaos. Wiki it's not a perfect techonology for maitaing disussions. -1 for using WIKI for dissusion +1 for using WIKI for writing down the things which were agreed. Michal
Processing Versions
> Adam R. B. Jack wrote: > > >So one can look at a repository of artefacts and select the "best" for the > >user automatically. Each user has a different view of "best", some want > >latest (nightly/snapshot), some want latest "release" only. > > > >Having a repository with automated tools that require humans to understand > >the contents kinda breaks the automation... > > "Michal Maczka" <[EMAIL PROTECTED]> wrote: > Not necesserly the fact that version number is not parsable by machines > determines that fact that versions are uncomparable. That sounds more like a 20/80 rule, i.e. you can't for some -- so don't bother for all. ;-) Who is to say we couldn't get some sort of agreement amongst apache software? IT doesn't have to be today, maybe later, but I feel it is critical that the artifacts are "understandable" in order to allow intelligent processing. Two versions only need to be comparable with others within their own namespace, not against all others. > Simply metdata atached to artifacts (which can be denoted as URL) is > not sufficient for making smart tools and never be. I know, I completely agree, it is not for all cases. But, I believe we set a miniumum bar that a repository ought be able to do a mimimum set of things even without metadata. If we can't build a tool to download the "right" jar without metadata we have the bar too low. > Artifact versioning is horribly complicated topic and I am simply afraid > that attempts to e.g. guess version precedence from version strings > are not relaiable in the best case. Yes, but there are some established standards -- it isn't all chaos: http://jakarta.apache.org/commons/versioning.html http://java.sun.com/j2se/1.4.2/docs/guide/extensions/versioning.html Metadata could inform a tool what version standard it adheres to, or not, and tools could then leverage. I think stating a versioning scheme (should one exist) is much better than positional metadata. I might be hoping for too much, but I think it is worth considering, especially within the confines of an Apache repository. Let's take this to Wiki [I'll figure out a way]. I (clearly) have a bias towards trying to process/understand versions ( see http://www.krysalis.org/version ) -- but I'm *NOT* trying to force this on the repository, just trying to ensure that version processing doesn't get overlook accidentally, only intentionally [if it doesn't fit]. regards Adam
