Niall Pemberton wrote: > On Sun, Mar 7, 2010 at 5:28 PM, Dennis Lundberg <denn...@apache.org> wrote: >> On 2010-03-07 16:45, Niall Pemberton wrote: >>> On Sun, Mar 7, 2010 at 3:28 PM, Dennis Lundberg <denn...@apache.org> wrote: >>>> On 2010-03-07 12:41, Niall Pemberton wrote: >>>>> On Sat, Mar 6, 2010 at 12:15 AM, sebb <seb...@gmail.com> wrote: >>>>>> The trunk pom.xml refers to 1.5-SNAPSHOT, but it seems to me that the >>>>>> next release should be 2.0 rather 1.5, as IO now requires Java 1.5, >>>>>> that requires a major version change. >>>>> The plan was to release it as 2.0 - but IMO its not a requirement. >>>>> >>>>> >>>>>> Does that make sense? >>>>>> If so, then the maven id can also be fixed (see IO-125). >>>>> -1 - see comments on JIRA ticket >>>> We need to make this switch sooner rather than later. Currently every >>>> release with a groupId och commons-* requires manual work from the >>>> people who manage Maven central repository. We're just about the only >>>> Apache project left not using a groupId of org.apache.*. >>> I thought it was only when we did the first m2 release for a component >>> and not for subsequent m2 releases for the group. Is that not the >>> case? >> It used to be that way, but it has changed. The repo maintainers want to >> remove all manual stuff, including anything from Apache that is not >> under groupId org.apache.*. We (the ASF) don't want anything pushed to >> the central repository that is from under groupId other than org.apache.*. >> >> It is only a matter of time before our current way (groupid commons-*) >> will be shut down completely. If people have opinions about this I >> suggest that you take them to reposit...@a.o for discussion. > > OK
I think we need to have that discussion. We (Commons) are happy to contribute to and subsequently follow ASF policy on how we publish maven artifacts. Unless I missed it on repository@, though, we have not as ASF agreed on a policy to retire the "legacy" groupIds. We also seem to be lacking consensus / clarity on how exactly we can accomplish "relocation" without potentially serious implications for the users of heavily-depended-on components. Therefore here in commons, I think we have agreed that we will move to org.apache.commons groupId when we make incompatible changes in a new release. That *must* coincide with a major release and it *may* coincide with a change in package name. It is possible, as in the present case with [io], that a major release will not introduce incompatible API changes, in which case we will not change the groupId. I see us cutting patch releases using "legacy" IDs for some time to come. Please commons ppl respond if you disagree with the statements above. Assuming we are in agreement, we can continue the discussion on repository@ Phil > >>>> We have previously said that we should make the switch to a groupId of >>>> org.apache.commons when we do a major release. IMO we need to stick by >>>> that decision. >>> I don't remember that decision, do you have a link to the thread? Even >>> if we did - this is going to cause problems for users who change their >>> dependency to the latest - but also depend on other artifacts that >>> have an older dependency on commons-io. Is this user pain worth it? >> I found this thread, which touches the issue: >> >> http://markmail.org/message/l3oezqvhehscm67l >> >> For such a change to be totally transparent we cannot rely on the >> relocation feature of Maven, which has been discussed before. We would >> have to change the package name, which I think was done in lang, from >> org.apache.commons.io to org.apache.commons.io2. > > I'm sorry but having the build-tool/repository force a package rename is nuts. > > Niall > >>> Niall >>> >>>>> Niall > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
