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 <[email protected] > >> > >wrote: > >> > > >> > > So, I've changed jclouds into an org and folks should have access to > >> make > >> > > changes needed to redirect repos and run the project with minimal > >> changes > >> > > for now. > >> > > > >> > > It seems clear from others there's no sense in making new orgs, so > >> let's > >> > > drop the idea. Thanks for the participation folks! > >> > > > >> > > -A > >> > > > >> > > > >> > > On Mon, May 6, 2013 at 9:46 AM, Adrian Cole < > [email protected] > >> > >wrote: > >> > > > >> > >> Hi, team. > >> > >> > >> > >> Folks have expressed interest in continuing use of github for the > >> > purpose > >> > >> of review. I've discussed a plan for how we can transition and > >> figured > >> > it > >> > >> best to repost it here. The idea is to have a place for legacy > code > >> > >> updates to occur from until the end of the year, and make space for > >> the > >> > >> next line of collaboration. > >> > >> > >> > >> Current status: > >> > >> > >> > >> jclouds on github is an account controlled only by me. This > includes > >> > the > >> > >> repositories being imported into the ASF prefixed with incubator- > >> > >> > >> > >> Ideal status (subject to debate): > >> > >> > >> > >> jclouds on github is an org with representative members correlating > >> to > >> > >> the PPMC. It contains forked repositories from the authoritative > >> > sources > >> > >> in apache. > >> > >> jclouds-legacy on github is an org with representative members > >> > >> correlating to the PPMC. Its repositories are the old ones, which > >> were > >> > >> transferred to it. These repositories and the account are marked > as > >> > >> deprecated. > >> > >> > >> > >> I've already provisioned the org jclouds-legacy, and migrating > repos > >> to > >> > >> it is pretty trivial. Converting the existing jclouds account to > an > >> > org is > >> > >> very easy. In other words, this process from a technical POV is > >> > stupidly > >> > >> simple. > >> > >> > >> > >> This all in mind, let's chat about any blocking concerns. If there > >> > >> aren't any, we should start the process so that we can start using > >> > github > >> > >> as a collaboration point for code updates into the ASF. > >> > >> > >> > >> you're on! > >> > >> > >> > > > >> > > > >> > > >> > > > > >
