Re: cool uris don't change, don't they ?
Good point. I think in general mirrors should be able to choose whatever subset they want. But apache should maintain at lest "the latest version of each point release" Mark R. Diggory wrote: With the amount of versioning going on, eventually a release falls into a state of non-usage, I suspect there should be room for such a mechanism, otherwise mirrors will become bloated with unused, outdated, antiquated and obsolete content. I suspect some sort of "redirect" mechanism would be sufficient in cases where an unmirrored archive is used. Something that most web servers support (for instance Apache Httpd and .htaccess files) Existing Example: archives.apache.org represents content from www.apache.org/dist that has been "decommissioned" from the mirroring process, of course mirrors may maintain copies of these files by not deleting contents. Ideally, such a mechanism could even be automated based on historical download information on the resource. I.E. if the resource hasn't been downloaded in 5 years, move it into an archive and provide a redirect or notice. -Mark Nick Chalko wrote: Patrick Chanezon wrote: Did you specify a lifecycle for artifacts, with some durations, and a process to decommision them ? Good question. This may be something to put to the board. My general thought are. "Released" version should live forever, unless a security or other fatal flaw is found in a release. As a minimum I think the latest version of each point release should be kept ie 1.2.x. R, Nick
Re: cool uris don't change, don't they ?
With the amount of versioning going on, eventually a release falls into a state of non-usage, I suspect there should be room for such a mechanism, otherwise mirrors will become bloated with unused, outdated, antiquated and obsolete content. I suspect some sort of "redirect" mechanism would be sufficient in cases where an unmirrored archive is used. Something that most web servers support (for instance Apache Httpd and .htaccess files) Existing Example: archives.apache.org represents content from www.apache.org/dist that has been "decommissioned" from the mirroring process, of course mirrors may maintain copies of these files by not deleting contents. Ideally, such a mechanism could even be automated based on historical download information on the resource. I.E. if the resource hasn't been downloaded in 5 years, move it into an archive and provide a redirect or notice. -Mark Nick Chalko wrote: Patrick Chanezon wrote: Did you specify a lifecycle for artifacts, with some durations, and a process to decommision them ? Good question. This may be something to put to the board. My general thought are. "Released" version should live forever, unless a security or other fatal flaw is found in a release. As a minimum I think the latest version of each point release should be kept ie 1.2.x. R, Nick -- Mark Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu
Re: cool uris don't change, don't they ?
Patrick Chanezon wrote: Did you specify a lifecycle for artifacts, with some durations, and a process to decommision them ? Good question. This may be something to put to the board. My general thought are. "Released" version should live forever, unless a security or other fatal flaw is found in a release. As a minimum I think the latest version of each point release should be kept ie 1.2.x. R, Nick
cool uris don't change, don't they ?
Hi all, I've been lurking in that list (repository) for a while, because the topic of repositories is of interest to me. I think that maven will have a big effect on java development and I understand that the apache repository will be where maven stores its jars (not sure about that but that would make sense, cross posting to maven-dev). I just wanted to check if you quantified or considered the requirement about how long you would keep artifacts at their url. Today I experienced some broken build with an unofficial makefile that helps build a system called Syncato (details at http://www.chanezon.com/pat/weblog/archives/000131.html). Rick Bradley's syncatomatic is a hack, and it broke because it made assumptions about xerces 2.3 source distribution to be hosted on an apache mirror. I thought: no big deal for a quick hack like this, designed to help people out temporarily. But when most java software gets built using maven, I guess you don't want that kind of things to happen. And it could happen all over the place, in a few years, if old version of artifacts get decommissionned wihtout warning. Did you specify a lifecycle for artifacts, with some durations, and a process to decommision them ? Also maybe when decommisioning time approaches, the server could notify maven, and maven could issue some warnings, pretty much like deprecation messages in java compilation, so that developers get warned that they should upgrade to a newer library. P@
