Sorry, I was referring to the mirroring of the ASF repos. A
On May 11, 2013, at 7:38 AM, Adrian Cole <[email protected]> wrote: > Which "this" are you referring to? :) > > On Friday, May 10, 2013, Andrew Bayer wrote: > >> So I may be missing something, but there isn't a way to do this >> automatically, without an update script we own running on some box we >> control, is there? >> >> A >> >> >> >> On May 10, 2013, at 5:09 PM, Andrew Bayer <[email protected]> wrote: >> >>> I was a little more concerned about this before seeing that we don't >> actually have many RAT license violations outside of incubator-jclouds-labs >> - but we have quite a few there. We need to remember that any release >> coming out of ASF has to pass license criteria, etc, so we'll have to deal >> with missing licenses/dependencies we can't use/etc in all branches we want >> to release, not just master onward. >>> >>> A. >>> >>> On Fri, May 10, 2013 at 4:39 PM, Adrian Cole <[email protected]> >> wrote: >>> This thread got long, so I figure it best to paraphrase where we ended >> up. >>> >>> We will release 1.5.x and 1.6.x releases from our ASF repos. It is >> likely >>> that our first ASF release will be 1.6.1, and we've probably a couple >> weeks >>> before timing of this becomes critical. >>> >>> There's a distribution implication of this that was probably not realized >>> by everyone. Although I'm ok with the implication, I think everyone >> should >>> bear below in mind. >>> >>> ASF releases are published to ASF repositories as opposed to sonatype. >> In >>> Sonatype, we publish to the group id org.jclouds. In ASF we need to >>> publish to org.apache.jclouds. >>> >>> When these jars are published, users will need to change their >> dependencies >>> like below: >>> >>> compile 'org.jclouds.provider:dynect:1.6.0' >>> compile 'org.apache.jclouds.provider:dynect:1.6.1' >>> >>> There are folks that use wildcard versions, or version properties, etc. >>> that would have maintenance to do to change the groupid that 1.6.1 now >>> correlates to. In other words, changing group ids will be at least a >> small >>> pain for a patch release, and likely lead to at least a question or two >> on >>> the user list about some classpath problem. >>> >>> My personal take is that the potential classpath problem for those who >> have >>> old and new versions is inevitable. It will happen in 1.7 or 1.6, and >> heck >>> even happens without a groupId change often enough. I also feel like >>> changing this sooner is better. That said there's more to it. I >>> personally am disinterested in the extra overhead we'd need to have 2 >>> different release processes. It would be one thing if jclouds had a >>> company staffed to do releases, but we aren't. Choosing to optimize >>> for multiple distributions has high impact for us, so we should be >> careful >>> about that. >>> >>> If we wanted to continue to publish to the old ids, I'd probably prefer >>> this as a secondary task. For example, we could upload a org.jclouds dir >>> to sonatype after renaming the directories and a recursive sed to apply >> the >>> old group id. In other words, it is far easier to republish a dist to >> the >>> old group id ad-hoc than maintaining parallel build infrastructure. >>> >>> In summary, doing an efficient 1.6.1 in ASF comes with a little baggage: >>> either a dual-publish or a concession of slight pom break. Even-though >> the >>> code we are distributing will be compatible, we should be aware that the >>> build side of things has impact. >>> >>> -A >>> >>> >>> >>> >>> On Fri, May 10, 2013 at 2:37 PM, Adrian Cole <[email protected] >>> wrote: >>> >>>> Thanks for the offer! >>>> >>>> >>>> On Fri, May 10, 2013 at 12:53 PM, Andrew Bayer <[email protected] >>> wrote: >>>> >>>>> I'll make a run at it this weekend. >>>>> >>>>> A. >>>>> >>>>> On Thu, May 9, 2013 at 2:19 PM, Adrian Cole <[email protected]> >>>>> wrote: >>>>> >>>>>> Any volunteers able to see this through? >>>>>> >>>>>> https://issues.apache.org/jira/browse/JCLOUDS-13 >>>>>> >>>>>> >>>>>> On Tue, May 7, 2013 at 10:11 AM, Adrian Cole <adrian.f.cole@gmai
