On 9/1/06, Craig McClanahan <[EMAIL PROTECTED]> wrote:
On 9/1/06, Phil Steitz <[EMAIL PROTECTED]> wrote: >
> <snip> > We also need to definitively settle the artifact naming conventions > and think carefully about the impact of relocating the fileupload jar. I *think* the following strategy will deal with this situation ... and should generic to all the commons packages: * If version x.y.z of Commons package "foo" is published as Maven artifact "commons-foo:commons-foo:x.y.z", publish an *additional* copy of that same version under "org.apache.commons.foo:commons-foo:x.y.z".
Just copying would make the metadata inconsistent, I assume, so I guess what we would need to do for *released* artifacts would be to copy the release tag to a new branch, create/edit a pom resolving to org.apache.commons.foo:commons-foo:x.y.z, tag this (and the copied release branch) and then publish. That way the new version has a reproducible build. Before doing this, though, we need to tag and release the commons parent pom. There may also be config changes required to get the previous release branch to build correctly under m2. Since to use the relocated jar, users are going to have to change their dependency specs anyway, I am thinking now that it might be better to increment the version number by a minor increment in the process. It's probably also a good idea to push an rc out and vote before final publication as well. So I guess what I am suggesting is that as part of the m2 migration, we get the most recent release re-released with a minor increment and whatever config changes are required to get things to work under m2. Then back port the config changes to trunk and continue in m2. Ugh. This now looks like too much work, so maybe its better to just wait for the next release or figure out how to deploy the artifacts with incorrect or munged metadata. I don't like the latter so much, because of the build reproducibility issue. For snapshots, i.e. n-SNAPSHOT versions, I think it is probably OK to just post a notice here and to commons-user and move - i.e., stop publishing the snaps in the "old" location and start publishing them in the new one.
* For all future versions, use only the"org.apache.commons" group id. That way, we won't disrupt current Maven-based users of the current versions, and we also don't have to wait until each individual package revs to publish versions under the new id. Users who are updating their projects to depend on a new version number can easily update the group id at the same time. Does that make any sense?
Yes, could be I am making more of this than it is. Let's at least all agree now that moving forward we publish under the group id "org.apache.commons." Phil --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
