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
