You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jclouds.apache.org by Olivier Lamy <ol...@apache.org> on 2013/05/19 13:01:05 UTC
release 1.6 etc with groupId change
Hi,
With my maven hat, I find that a bit "huge trouble for users" to
change the maven groupId but not the java package.
With transitive dependency (or any other pom configuration), you can
have both the jars from the previous groupId and new groupId and with
the same java package.
So possible duplicate classes from different jars!
None have issues with that ?
What about change java package to o.a.j in master and release 2.0 first ?
Cheers
--
Olivier Lamy
Ecetera: http://ecetera.com.au
http://twitter.com/olamy | http://linkedin.com/in/olamy
Re: release 1.6 etc with groupId change
Posted by Adrian Cole <ad...@gmail.com>.
Sorry, wrong reference thread. The idea started with David's comment
on May 6 8:23pm.
http://markmail.org/thread/cv27odkhch7x4bti
On Sun, May 19, 2013 at 10:45 AM, Adrian Cole <ad...@gmail.com> wrote:
> Hi, Olivier.
>
> Happy to discuss this again. We started it in this thread for your reference:
> http://markmail.org/thread/b7vfhitwbqos74x5
>
> Arising from advice from David, we decided against a "big bang'
> release and instead focus on ASF distribution of artifacts from 1.5.x,
> 1.6.x, and master branches. A lot of work went into that and we are
> already publishing snapshots some of us are consuming. The plan
> currently is to release 1.6.1 from the 1.6.x branch in the next week
> or so.
>
> Master clearly is intended to have a package rename, and blocked on
> that. Since ASF rules don't mandate a package change, I think it is
> for the better to continue course and release ASF 1.5.11, 1.6.1 with
> the old java packages, and do 1.7 or 2.0 with the new ones.
>
> If there are community members who like to cut a release outside the
> ASF, using the old group id, they can always do so from a fork.
>
> HTH.
> -A
>
>
> On Sun, May 19, 2013 at 4:01 AM, Olivier Lamy <ol...@apache.org> wrote:
>> Hi,
>> With my maven hat, I find that a bit "huge trouble for users" to
>> change the maven groupId but not the java package.
>>
>> With transitive dependency (or any other pom configuration), you can
>> have both the jars from the previous groupId and new groupId and with
>> the same java package.
>> So possible duplicate classes from different jars!
>>
>> None have issues with that ?
>> What about change java package to o.a.j in master and release 2.0 first ?
>>
>> Cheers
>> --
>> Olivier Lamy
>> Ecetera: http://ecetera.com.au
>> http://twitter.com/olamy | http://linkedin.com/in/olamy
Re: release 1.6 etc with groupId change
Posted by Adrian Cole <ad...@gmail.com>.
Hi, Olivier.
Happy to discuss this again. We started it in this thread for your reference:
http://markmail.org/thread/b7vfhitwbqos74x5
Arising from advice from David, we decided against a "big bang'
release and instead focus on ASF distribution of artifacts from 1.5.x,
1.6.x, and master branches. A lot of work went into that and we are
already publishing snapshots some of us are consuming. The plan
currently is to release 1.6.1 from the 1.6.x branch in the next week
or so.
Master clearly is intended to have a package rename, and blocked on
that. Since ASF rules don't mandate a package change, I think it is
for the better to continue course and release ASF 1.5.11, 1.6.1 with
the old java packages, and do 1.7 or 2.0 with the new ones.
If there are community members who like to cut a release outside the
ASF, using the old group id, they can always do so from a fork.
HTH.
-A
On Sun, May 19, 2013 at 4:01 AM, Olivier Lamy <ol...@apache.org> wrote:
> Hi,
> With my maven hat, I find that a bit "huge trouble for users" to
> change the maven groupId but not the java package.
>
> With transitive dependency (or any other pom configuration), you can
> have both the jars from the previous groupId and new groupId and with
> the same java package.
> So possible duplicate classes from different jars!
>
> None have issues with that ?
> What about change java package to o.a.j in master and release 2.0 first ?
>
> Cheers
> --
> Olivier Lamy
> Ecetera: http://ecetera.com.au
> http://twitter.com/olamy | http://linkedin.com/in/olamy
Re: release 1.6 etc with groupId change
Posted by Matt Stephenson <ma...@apache.org>.
We have this problem with some of the maven artifacts Google has published.
In our case, it has lead to stack overflow questions and some users
creating issues. I agree with Olivier.
On Sun, May 19, 2013 at 4:01 AM, Olivier Lamy <ol...@apache.org> wrote:
> Hi,
> With my maven hat, I find that a bit "huge trouble for users" to
> change the maven groupId but not the java package.
>
> With transitive dependency (or any other pom configuration), you can
> have both the jars from the previous groupId and new groupId and with
> the same java package.
> So possible duplicate classes from different jars!
>
> None have issues with that ?
> What about change java package to o.a.j in master and release 2.0 first ?
>
> Cheers
> --
> Olivier Lamy
> Ecetera: http://ecetera.com.au
> http://twitter.com/olamy | http://linkedin.com/in/olamy
>
Re: release 1.6 etc with groupId change
Posted by Matt Stephenson <ma...@mattstep.net>.
Lack of context on my end due to being heads-down last week. I'm not held
to either option strongly. Just adding a data point.
On Sun, May 19, 2013 at 5:27 PM, David Nalley <da...@gnsa.us> wrote:
> On Sun, May 19, 2013 at 9:47 AM, David Nalley <da...@gnsa.us> wrote:
> > On Sun, May 19, 2013 at 8:46 AM, Olivier Lamy <ol...@apache.org> wrote:
> >> 2013/5/19 Andrew Phillips <ap...@qrmedia.com>:
> >>>> With transitive dependency (or any other pom configuration), you can
> >>>> have both the jars from the previous groupId and new groupId and with
> >>>> the same java package.
> >>>
> >>>
> >>> I see your "Maven hat" point ;-)
> >>>
> >>> Having multiple versions of jclouds on the classpath usually causes
> other
> >>> problems independent of potential duplicate classes, though, so I
> think even
> >>> if we make a package change to avoid the duplicate packages, people
> with
> >>> multiple jclouds versions will still have problems.
> >>>
> >>> And if they need to avoid multiple jclouds versions on the classpath
> anyway,
> >>> this hopefully becomes at least less of a *practical* problem.
> >>>
> >>> Do you have any suggestions for the 1.6.x and 1.5.x branches, where the
> >>> group ID change has also been applied?
> >>> * Make the package change here too (which seems a rather large breaking
> >>> change for a minor release)?
> >>> * Revert the group ID change?
> >>> * Stop releasing anything off the 1.6.x and 1.5.x branches?
> >>> * Other?
> >>
> >> My personal POV.
> >> First, I don't really like the idea about releasing something here
> >> @apache with a package name org.jclouds. I'm definitely not sure if
> >> there is any policy for that (I can check if needed ?)
> >> Second, In all incubations projects I have participated, all made
> >> their first release @ apache changing the package name (but maybe that
> >> can change :-) ).
> >
> > So with the caveat that I'll defer to your judgement as the maven
> > expert and having been around much longer; CloudStack (with 3 releases
> > to date, and a 4th imminent) still has a lot of com.cloud packages,
> > and while we have a patch pending that cleans all of that up, because
> > of the various timelines, it isn't likely to be included in a release
> > until 2014.
> >
> >> Third, (perso) I don't have any issue seeing release of 1.x etc
> >> release under org.jclouds groupId and the previous package (except
> >> they cannot be considered as official Apache release). As changing the
> >> package for 1.x look a very bad idea.
> >>
> >> BTW that's my POV ! (and sure I can help on changing package name for
> >> master if needed :-) )
> >>
> >> /Olivier
> >>
>
> Olivier:
>
> I know you are likely not yet awake, but while spending some time away
> I figured I'd add the thoughts behind my reasoning, so you (maybe)
> think I am less crazy :)
>
> * jclouds is consumed by a lot of projects/products as a library,
> rather than just a standalone project. For what (based on version
> numbering norms, esp semver) would be considered a bugfix release
> (1.5.x or 1.6.x) wholesale package name changes is a pretty big
> upheaval for consumers to process.
>
> * the jclouds folks could continue releasing updates external to the
> ASF, but having 2/3 of your releases on an ongoing basis being done
> externally is not terribly effective at getting folks integrated into
> the ASF, and at least in my mind keeps them external as a community
> which isn't the goal IMO.
>
> * jclouds released 1.6.0 just days before entering the incubator, and
> if past history is any indication, it will be another 9-10 months
> before they are ready to begin the release process for 1.7.0, which is
> a really long time.
>
> Thoughts on the best path here?
>
> --David
>
Re: release 1.6 etc with groupId change
Posted by Everett Toews <ev...@RACKSPACE.COM>.
On May 20, 2013, at 2:02 PM, Ignasi wrote:
> +1 to release without changing the package for the 1.[56].x lines, and
> +1 to release with the -incubator classifier too.
+1 to these
I'd like to see the pom.xml snippet that David mentioned on how to prevent duplicate class issues using the maven enforcer rule (to exclude dependency from previous groupId) sooner than later.
Everett
Re: release 1.6 etc with groupId change
Posted by Ignasi <ig...@gmail.com>.
+1 to release without changing the package for the 1.[56].x lines, and
+1 to release with the -incubator classifier too.
On 20 May 2013 20:15, Andrew Phillips <ap...@qrmedia.com> wrote:
>> As to the whole package name question - I'm generally +1 on doing the
>> package move for anything we ship from ASF. As Adrian may remember, I just
>> assumed that was inherent in doing 1.6.1 as an ASF release. =) But
>> switching to org.apache.jclouds will mean breaking a lot of existing code,
>> and I can definitely see the reasoning behind keeping the org.jclouds
>> packages for the 1.5.x and 1.6.x lines to keep from breaking
>> compatibility.
>> I personally was in favor of keeping 1.5.x and 1.6.x releases out of ASF
>> for this sort of reason - I don't think it's a wise idea to make major
>> changes in existing release lines, either in terms of form or content.
>> Adrian made a very solid case for why we should do 1.5.x/1.6.x through ASF
>> rather than outside, and persuaded me, but retaining our existing package
>> names is, I think, critical, even though we're going through ASF with the
>> new groupIds.
>
>
> +1. Sounds like we feel we have a strong enough case to move forward with
> this?
>
> ap
Re: release 1.6 etc with groupId change
Posted by Andrew Phillips <ap...@qrmedia.com>.
> As to the whole package name question - I'm generally +1 on doing the
> package move for anything we ship from ASF. As Adrian may remember, I just
> assumed that was inherent in doing 1.6.1 as an ASF release. =) But
> switching to org.apache.jclouds will mean breaking a lot of existing code,
> and I can definitely see the reasoning behind keeping the org.jclouds
> packages for the 1.5.x and 1.6.x lines to keep from breaking compatibility.
> I personally was in favor of keeping 1.5.x and 1.6.x releases out of ASF
> for this sort of reason - I don't think it's a wise idea to make major
> changes in existing release lines, either in terms of form or content.
> Adrian made a very solid case for why we should do 1.5.x/1.6.x through ASF
> rather than outside, and persuaded me, but retaining our existing package
> names is, I think, critical, even though we're going through ASF with the
> new groupIds.
+1. Sounds like we feel we have a strong enough case to move forward
with this?
ap
Re: release 1.6 etc with groupId change
Posted by Andrew Bayer <an...@gmail.com>.
I think we can cheat on SNAPSHOTs and just do x.y.z-SNAPSHOT, but don't
quote me on that.
A.
On Mon, May 20, 2013 at 2:46 PM, Andrew Phillips <ap...@qrmedia.com>wrote:
> -SNAPSHOT's always last, no matter what. From what I've seen -incubating
>> ends up being last for releases, second-to-last for SNAPSHOTs.
>>
>
> Thanks for clarifying, AB. I guess that does mean the that
> "in-between-releases" version is "x.y.z-incubating-SNAPSHOT"? Quite a
> mouthful! ;-)
>
> Anyone else with ASF experience have any light to shed on this? Especially
> with regard to semver compliance?
>
> ap
>
Re: release 1.6 etc with groupId change
Posted by Andrew Phillips <ap...@qrmedia.com>.
> -SNAPSHOT's always last, no matter what. From what I've seen -incubating
> ends up being last for releases, second-to-last for SNAPSHOTs.
Thanks for clarifying, AB. I guess that does mean the that
"in-between-releases" version is "x.y.z-incubating-SNAPSHOT"? Quite a
mouthful! ;-)
Anyone else with ASF experience have any light to shed on this?
Especially with regard to semver compliance?
ap
Re: release 1.6 etc with groupId change
Posted by Andrew Bayer <an...@gmail.com>.
-SNAPSHOT's always last, no matter what. From what I've seen -incubating
ends up being last for releases, second-to-last for SNAPSHOTs.
A.
On Mon, May 20, 2013 at 2:27 PM, Andrew Phillips <ap...@qrmedia.com>wrote:
> I honestly don't know whether we'll still use the beta etc versions - the
>> actual voted-on RCs will all be the release version, not -rc.x, but we may
>> still want to do milestones with beta/alpha. In that case, the version
>> would be x.y.z-beta.x-incubating, I believe.
>>
>
> Ah interesting. So not x.y.z-incubating-beta.x? I had always envisaged the
> "-beta.x" part as a suffix to the "to be released" version which, if I
> understand it correctly, would now be "x.y.z-incubating"..?
>
> Same would go, incidentally, for "-SNAPSHOT" and other suffixes.
>
> ap
>
Re: release 1.6 etc with groupId change
Posted by Andrew Phillips <ap...@qrmedia.com>.
> I honestly don't know whether we'll still use the beta etc versions - the
> actual voted-on RCs will all be the release version, not -rc.x, but we may
> still want to do milestones with beta/alpha. In that case, the version
> would be x.y.z-beta.x-incubating, I believe.
Ah interesting. So not x.y.z-incubating-beta.x? I had always envisaged
the "-beta.x" part as a suffix to the "to be released" version which,
if I understand it correctly, would now be "x.y.z-incubating"..?
Same would go, incidentally, for "-SNAPSHOT" and other suffixes.
ap
Re: release 1.6 etc with groupId change
Posted by Andrew Bayer <an...@gmail.com>.
I honestly don't know whether we'll still use the beta etc versions - the
actual voted-on RCs will all be the release version, not -rc.x, but we may
still want to do milestones with beta/alpha. In that case, the version
would be x.y.z-beta.x-incubating, I believe.
A.
On Mon, May 20, 2013 at 1:46 PM, Andrew Phillips <ap...@qrmedia.com>wrote:
> Oh, and, on that subject (apologies if this is a stupid/RTFM question):
> are any of "-alpha.x", "-beta.x" or "-rc.x" still intended to be used? If
> so, what will the pattern by? "x.y.z-incubating-rc.x", for example?
>
> ap
>
Re: release 1.6 etc with groupId change
Posted by Andrew Phillips <ap...@qrmedia.com>.
Oh, and, on that subject (apologies if this is a stupid/RTFM
question): are any of "-alpha.x", "-beta.x" or "-rc.x" still intended
to be used? If so, what will the pattern by? "x.y.z-incubating-rc.x",
for example?
ap
Re: release 1.6 etc with groupId change
Posted by Andrew Phillips <ap...@qrmedia.com>.
> Oh yeah, I shoulda mentioned that one earlier - technically, it'd be nice
> if we were doing 1.6.1-incubating-SNAPSHOT, but that's not as much of an
> issue as the release bits. So I'm +1 on 1.6.1-incubating.
Just to be clear (as I'm about to start on a PR to change
JcloudsVersion): the plan is to have,
for releases: x.y.z-incubating
for snapshots: x.y.(z+1)-SNAPSHOT
or
for releases: x.y.z-incubating
for snapshots: x.y.(z+1)-incubating-SNAPSHOT
? From my reading of the semver spec [1], by the way,
"x.y.z-incubating" is not a semver-compliant release version :-(
Is semver compliance a topic for ASF releases?
[1] http://semver.org/
Re: release 1.6 etc with groupId change
Posted by Andrew Bayer <an...@gmail.com>.
Oh yeah, I shoulda mentioned that one earlier - technically, it'd be nice
if we were doing 1.6.1-incubating-SNAPSHOT, but that's not as much of an
issue as the release bits. So I'm +1 on 1.6.1-incubating.
As to the whole package name question - I'm generally +1 on doing the
package move for anything we ship from ASF. As Adrian may remember, I just
assumed that was inherent in doing 1.6.1 as an ASF release. =) But
switching to org.apache.jclouds will mean breaking a lot of existing code,
and I can definitely see the reasoning behind keeping the org.jclouds
packages for the 1.5.x and 1.6.x lines to keep from breaking compatibility.
I personally was in favor of keeping 1.5.x and 1.6.x releases out of ASF
for this sort of reason - I don't think it's a wise idea to make major
changes in existing release lines, either in terms of form or content.
Adrian made a very solid case for why we should do 1.5.x/1.6.x through ASF
rather than outside, and persuaded me, but retaining our existing package
names is, I think, critical, even though we're going through ASF with the
new groupIds.
A.
On Sun, May 19, 2013 at 7:37 PM, Adrian Cole <ad...@gmail.com>wrote:
> sounds like an easy one :)
>
> +1 to set the version as 1.6.1-incubating when the release is cut.
>
> On Sun, May 19, 2013 at 7:29 PM, Andrew Phillips <ap...@qrmedia.com>
> wrote:
> >> The issue will be about the version name which must end with
> >> -incubating as long as the project is not a tlp (I think some folks
> >> will complain on that during the release vote). 1.6.1-incubating
> >> rather than 1.6.1.
> >> Someone have issue with this naming ? (or maybe it's simply not an
> issue
> >> :-) )
> >
> >
> > One quick technical point: we'd need to make a change to the
> JcloudsVersion
> > class [1] to handle the new name. Not a huge deal by any means, just so
> that
> > we don't forget ;-)
> >
> > ap
> >
> > [1]
> >
> https://git-wip-us.apache.org/repos/asf?p=incubator-jclouds.git;a=blob;f=core/src/main/java/org/jclouds/JcloudsVersion.java;h=731eb089a67814b4f6a2fa3f95a6de10f0b81e4d;hb=HEAD
>
Re: release 1.6 etc with groupId change
Posted by Adrian Cole <ad...@gmail.com>.
sounds like an easy one :)
+1 to set the version as 1.6.1-incubating when the release is cut.
On Sun, May 19, 2013 at 7:29 PM, Andrew Phillips <ap...@qrmedia.com> wrote:
>> The issue will be about the version name which must end with
>> -incubating as long as the project is not a tlp (I think some folks
>> will complain on that during the release vote). 1.6.1-incubating
>> rather than 1.6.1.
>> Someone have issue with this naming ? (or maybe it's simply not an issue
>> :-) )
>
>
> One quick technical point: we'd need to make a change to the JcloudsVersion
> class [1] to handle the new name. Not a huge deal by any means, just so that
> we don't forget ;-)
>
> ap
>
> [1]
> https://git-wip-us.apache.org/repos/asf?p=incubator-jclouds.git;a=blob;f=core/src/main/java/org/jclouds/JcloudsVersion.java;h=731eb089a67814b4f6a2fa3f95a6de10f0b81e4d;hb=HEAD
Re: release 1.6 etc with groupId change
Posted by Andrew Phillips <ap...@qrmedia.com>.
> The issue will be about the version name which must end with
> -incubating as long as the project is not a tlp (I think some folks
> will complain on that during the release vote). 1.6.1-incubating
> rather than 1.6.1.
> Someone have issue with this naming ? (or maybe it's simply not an
> issue :-) )
One quick technical point: we'd need to make a change to the
JcloudsVersion class [1] to handle the new name. Not a huge deal by
any means, just so that we don't forget ;-)
ap
[1]
https://git-wip-us.apache.org/repos/asf?p=incubator-jclouds.git;a=blob;f=core/src/main/java/org/jclouds/JcloudsVersion.java;h=731eb089a67814b4f6a2fa3f95a6de10f0b81e4d;hb=HEAD
Re: release 1.6 etc with groupId change
Posted by Matt Stephenson <ma...@mattstep.net>.
Can we shadow these releases on org.jclouds for 1.6? I'm happy to spend
cycles doing that.
On Sun, May 19, 2013 at 6:23 PM, Olivier Lamy <ol...@apache.org> wrote:
> 2013/5/20 David Nalley <da...@gnsa.us>:
> > On Sun, May 19, 2013 at 9:47 AM, David Nalley <da...@gnsa.us> wrote:
> >> On Sun, May 19, 2013 at 8:46 AM, Olivier Lamy <ol...@apache.org> wrote:
> >>> 2013/5/19 Andrew Phillips <ap...@qrmedia.com>:
> >>>>> With transitive dependency (or any other pom configuration), you can
> >>>>> have both the jars from the previous groupId and new groupId and
> with
> >>>>> the same java package.
> >>>>
> >>>>
> >>>> I see your "Maven hat" point ;-)
> >>>>
> >>>> Having multiple versions of jclouds on the classpath usually causes
> other
> >>>> problems independent of potential duplicate classes, though, so I
> think even
> >>>> if we make a package change to avoid the duplicate packages, people
> with
> >>>> multiple jclouds versions will still have problems.
> >>>>
> >>>> And if they need to avoid multiple jclouds versions on the classpath
> anyway,
> >>>> this hopefully becomes at least less of a *practical* problem.
> >>>>
> >>>> Do you have any suggestions for the 1.6.x and 1.5.x branches, where
> the
> >>>> group ID change has also been applied?
> >>>> * Make the package change here too (which seems a rather large
> breaking
> >>>> change for a minor release)?
> >>>> * Revert the group ID change?
> >>>> * Stop releasing anything off the 1.6.x and 1.5.x branches?
> >>>> * Other?
> >>>
> >>> My personal POV.
> >>> First, I don't really like the idea about releasing something here
> >>> @apache with a package name org.jclouds. I'm definitely not sure if
> >>> there is any policy for that (I can check if needed ?)
> >>> Second, In all incubations projects I have participated, all made
> >>> their first release @ apache changing the package name (but maybe that
> >>> can change :-) ).
> >>
> >> So with the caveat that I'll defer to your judgement as the maven
> >> expert and having been around much longer; CloudStack (with 3 releases
> >> to date, and a 4th imminent) still has a lot of com.cloud packages,
> >> and while we have a patch pending that cleans all of that up, because
> >> of the various timelines, it isn't likely to be included in a release
> >> until 2014.
> >>
> >>> Third, (perso) I don't have any issue seeing release of 1.x etc
> >>> release under org.jclouds groupId and the previous package (except
> >>> they cannot be considered as official Apache release). As changing the
> >>> package for 1.x look a very bad idea.
> >>>
> >>> BTW that's my POV ! (and sure I can help on changing package name for
> >>> master if needed :-) )
> >>>
> >>> /Olivier
> >>>
> >
> > Olivier:
> >
> > I know you are likely not yet awake, but while spending some time away
> > I figured I'd add the thoughts behind my reasoning, so you (maybe)
> > think I am less crazy :)
>
> No I'm awake (I relocated 2 months ago so my timezone has changed a lot
> :-)).
>
> >
> > * jclouds is consumed by a lot of projects/products as a library,
> > rather than just a standalone project. For what (based on version
> > numbering norms, esp semver) would be considered a bugfix release
> > (1.5.x or 1.6.x) wholesale package name changes is a pretty big
> > upheaval for consumers to process.
> >
> > * the jclouds folks could continue releasing updates external to the
> > ASF, but having 2/3 of your releases on an ongoing basis being done
> > externally is not terribly effective at getting folks integrated into
> > the ASF, and at least in my mind keeps them external as a community
> > which isn't the goal IMO.
> >
> > * jclouds released 1.6.0 just days before entering the incubator, and
> > if past history is any indication, it will be another 9-10 months
> > before they are ready to begin the release process for 1.7.0, which is
> > a really long time.
> >
> > Thoughts on the best path here?
> >
>
> I think releasing with org.jclouds package and apache groupId is not
> an issue (at least for me!) as I don't see any special rules on that.
> We can document how to prevent issues with using maven enforcer rule
> (to exclude dependency from previous groupId)
>
> The issue will be about the version name which must end with
> -incubating as long as the project is not a tlp (I think some folks
> will complain on that during the release vote). 1.6.1-incubating
> rather than 1.6.1.
> Someone have issue with this naming ? (or maybe it's simply not an issue
> :-) )
>
>
>
> > --David
>
>
>
> --
> Olivier Lamy
> Ecetera: http://ecetera.com.au
> http://twitter.com/olamy | http://linkedin.com/in/olamy
>
Re: release 1.6 etc with groupId change
Posted by Olivier Lamy <ol...@apache.org>.
2013/5/20 David Nalley <da...@gnsa.us>:
> On Sun, May 19, 2013 at 9:47 AM, David Nalley <da...@gnsa.us> wrote:
>> On Sun, May 19, 2013 at 8:46 AM, Olivier Lamy <ol...@apache.org> wrote:
>>> 2013/5/19 Andrew Phillips <ap...@qrmedia.com>:
>>>>> With transitive dependency (or any other pom configuration), you can
>>>>> have both the jars from the previous groupId and new groupId and with
>>>>> the same java package.
>>>>
>>>>
>>>> I see your "Maven hat" point ;-)
>>>>
>>>> Having multiple versions of jclouds on the classpath usually causes other
>>>> problems independent of potential duplicate classes, though, so I think even
>>>> if we make a package change to avoid the duplicate packages, people with
>>>> multiple jclouds versions will still have problems.
>>>>
>>>> And if they need to avoid multiple jclouds versions on the classpath anyway,
>>>> this hopefully becomes at least less of a *practical* problem.
>>>>
>>>> Do you have any suggestions for the 1.6.x and 1.5.x branches, where the
>>>> group ID change has also been applied?
>>>> * Make the package change here too (which seems a rather large breaking
>>>> change for a minor release)?
>>>> * Revert the group ID change?
>>>> * Stop releasing anything off the 1.6.x and 1.5.x branches?
>>>> * Other?
>>>
>>> My personal POV.
>>> First, I don't really like the idea about releasing something here
>>> @apache with a package name org.jclouds. I'm definitely not sure if
>>> there is any policy for that (I can check if needed ?)
>>> Second, In all incubations projects I have participated, all made
>>> their first release @ apache changing the package name (but maybe that
>>> can change :-) ).
>>
>> So with the caveat that I'll defer to your judgement as the maven
>> expert and having been around much longer; CloudStack (with 3 releases
>> to date, and a 4th imminent) still has a lot of com.cloud packages,
>> and while we have a patch pending that cleans all of that up, because
>> of the various timelines, it isn't likely to be included in a release
>> until 2014.
>>
>>> Third, (perso) I don't have any issue seeing release of 1.x etc
>>> release under org.jclouds groupId and the previous package (except
>>> they cannot be considered as official Apache release). As changing the
>>> package for 1.x look a very bad idea.
>>>
>>> BTW that's my POV ! (and sure I can help on changing package name for
>>> master if needed :-) )
>>>
>>> /Olivier
>>>
>
> Olivier:
>
> I know you are likely not yet awake, but while spending some time away
> I figured I'd add the thoughts behind my reasoning, so you (maybe)
> think I am less crazy :)
No I'm awake (I relocated 2 months ago so my timezone has changed a lot :-)).
>
> * jclouds is consumed by a lot of projects/products as a library,
> rather than just a standalone project. For what (based on version
> numbering norms, esp semver) would be considered a bugfix release
> (1.5.x or 1.6.x) wholesale package name changes is a pretty big
> upheaval for consumers to process.
>
> * the jclouds folks could continue releasing updates external to the
> ASF, but having 2/3 of your releases on an ongoing basis being done
> externally is not terribly effective at getting folks integrated into
> the ASF, and at least in my mind keeps them external as a community
> which isn't the goal IMO.
>
> * jclouds released 1.6.0 just days before entering the incubator, and
> if past history is any indication, it will be another 9-10 months
> before they are ready to begin the release process for 1.7.0, which is
> a really long time.
>
> Thoughts on the best path here?
>
I think releasing with org.jclouds package and apache groupId is not
an issue (at least for me!) as I don't see any special rules on that.
We can document how to prevent issues with using maven enforcer rule
(to exclude dependency from previous groupId)
The issue will be about the version name which must end with
-incubating as long as the project is not a tlp (I think some folks
will complain on that during the release vote). 1.6.1-incubating
rather than 1.6.1.
Someone have issue with this naming ? (or maybe it's simply not an issue :-) )
> --David
--
Olivier Lamy
Ecetera: http://ecetera.com.au
http://twitter.com/olamy | http://linkedin.com/in/olamy
Re: release 1.6 etc with groupId change
Posted by David Nalley <da...@gnsa.us>.
On Sun, May 19, 2013 at 9:47 AM, David Nalley <da...@gnsa.us> wrote:
> On Sun, May 19, 2013 at 8:46 AM, Olivier Lamy <ol...@apache.org> wrote:
>> 2013/5/19 Andrew Phillips <ap...@qrmedia.com>:
>>>> With transitive dependency (or any other pom configuration), you can
>>>> have both the jars from the previous groupId and new groupId and with
>>>> the same java package.
>>>
>>>
>>> I see your "Maven hat" point ;-)
>>>
>>> Having multiple versions of jclouds on the classpath usually causes other
>>> problems independent of potential duplicate classes, though, so I think even
>>> if we make a package change to avoid the duplicate packages, people with
>>> multiple jclouds versions will still have problems.
>>>
>>> And if they need to avoid multiple jclouds versions on the classpath anyway,
>>> this hopefully becomes at least less of a *practical* problem.
>>>
>>> Do you have any suggestions for the 1.6.x and 1.5.x branches, where the
>>> group ID change has also been applied?
>>> * Make the package change here too (which seems a rather large breaking
>>> change for a minor release)?
>>> * Revert the group ID change?
>>> * Stop releasing anything off the 1.6.x and 1.5.x branches?
>>> * Other?
>>
>> My personal POV.
>> First, I don't really like the idea about releasing something here
>> @apache with a package name org.jclouds. I'm definitely not sure if
>> there is any policy for that (I can check if needed ?)
>> Second, In all incubations projects I have participated, all made
>> their first release @ apache changing the package name (but maybe that
>> can change :-) ).
>
> So with the caveat that I'll defer to your judgement as the maven
> expert and having been around much longer; CloudStack (with 3 releases
> to date, and a 4th imminent) still has a lot of com.cloud packages,
> and while we have a patch pending that cleans all of that up, because
> of the various timelines, it isn't likely to be included in a release
> until 2014.
>
>> Third, (perso) I don't have any issue seeing release of 1.x etc
>> release under org.jclouds groupId and the previous package (except
>> they cannot be considered as official Apache release). As changing the
>> package for 1.x look a very bad idea.
>>
>> BTW that's my POV ! (and sure I can help on changing package name for
>> master if needed :-) )
>>
>> /Olivier
>>
Olivier:
I know you are likely not yet awake, but while spending some time away
I figured I'd add the thoughts behind my reasoning, so you (maybe)
think I am less crazy :)
* jclouds is consumed by a lot of projects/products as a library,
rather than just a standalone project. For what (based on version
numbering norms, esp semver) would be considered a bugfix release
(1.5.x or 1.6.x) wholesale package name changes is a pretty big
upheaval for consumers to process.
* the jclouds folks could continue releasing updates external to the
ASF, but having 2/3 of your releases on an ongoing basis being done
externally is not terribly effective at getting folks integrated into
the ASF, and at least in my mind keeps them external as a community
which isn't the goal IMO.
* jclouds released 1.6.0 just days before entering the incubator, and
if past history is any indication, it will be another 9-10 months
before they are ready to begin the release process for 1.7.0, which is
a really long time.
Thoughts on the best path here?
--David
Re: release 1.6 etc with groupId change
Posted by David Nalley <da...@gnsa.us>.
On Sun, May 19, 2013 at 8:46 AM, Olivier Lamy <ol...@apache.org> wrote:
> 2013/5/19 Andrew Phillips <ap...@qrmedia.com>:
>>> With transitive dependency (or any other pom configuration), you can
>>> have both the jars from the previous groupId and new groupId and with
>>> the same java package.
>>
>>
>> I see your "Maven hat" point ;-)
>>
>> Having multiple versions of jclouds on the classpath usually causes other
>> problems independent of potential duplicate classes, though, so I think even
>> if we make a package change to avoid the duplicate packages, people with
>> multiple jclouds versions will still have problems.
>>
>> And if they need to avoid multiple jclouds versions on the classpath anyway,
>> this hopefully becomes at least less of a *practical* problem.
>>
>> Do you have any suggestions for the 1.6.x and 1.5.x branches, where the
>> group ID change has also been applied?
>> * Make the package change here too (which seems a rather large breaking
>> change for a minor release)?
>> * Revert the group ID change?
>> * Stop releasing anything off the 1.6.x and 1.5.x branches?
>> * Other?
>
> My personal POV.
> First, I don't really like the idea about releasing something here
> @apache with a package name org.jclouds. I'm definitely not sure if
> there is any policy for that (I can check if needed ?)
> Second, In all incubations projects I have participated, all made
> their first release @ apache changing the package name (but maybe that
> can change :-) ).
So with the caveat that I'll defer to your judgement as the maven
expert and having been around much longer; CloudStack (with 3 releases
to date, and a 4th imminent) still has a lot of com.cloud packages,
and while we have a patch pending that cleans all of that up, because
of the various timelines, it isn't likely to be included in a release
until 2014.
> Third, (perso) I don't have any issue seeing release of 1.x etc
> release under org.jclouds groupId and the previous package (except
> they cannot be considered as official Apache release). As changing the
> package for 1.x look a very bad idea.
>
> BTW that's my POV ! (and sure I can help on changing package name for
> master if needed :-) )
>
> /Olivier
>
>>
>> Suggestions appreciated!
>>
>> Thanks
>>
>> ap
Re: release 1.6 etc with groupId change
Posted by Olivier Lamy <ol...@apache.org>.
2013/5/19 Andrew Phillips <ap...@qrmedia.com>:
>> With transitive dependency (or any other pom configuration), you can
>> have both the jars from the previous groupId and new groupId and with
>> the same java package.
>
>
> I see your "Maven hat" point ;-)
>
> Having multiple versions of jclouds on the classpath usually causes other
> problems independent of potential duplicate classes, though, so I think even
> if we make a package change to avoid the duplicate packages, people with
> multiple jclouds versions will still have problems.
>
> And if they need to avoid multiple jclouds versions on the classpath anyway,
> this hopefully becomes at least less of a *practical* problem.
>
> Do you have any suggestions for the 1.6.x and 1.5.x branches, where the
> group ID change has also been applied?
> * Make the package change here too (which seems a rather large breaking
> change for a minor release)?
> * Revert the group ID change?
> * Stop releasing anything off the 1.6.x and 1.5.x branches?
> * Other?
My personal POV.
First, I don't really like the idea about releasing something here
@apache with a package name org.jclouds. I'm definitely not sure if
there is any policy for that (I can check if needed ?)
Second, In all incubations projects I have participated, all made
their first release @ apache changing the package name (but maybe that
can change :-) ).
Third, (perso) I don't have any issue seeing release of 1.x etc
release under org.jclouds groupId and the previous package (except
they cannot be considered as official Apache release). As changing the
package for 1.x look a very bad idea.
BTW that's my POV ! (and sure I can help on changing package name for
master if needed :-) )
/Olivier
>
> Suggestions appreciated!
>
> Thanks
>
> ap
Re: release 1.6 etc with groupId change
Posted by Andrew Phillips <ap...@qrmedia.com>.
> With transitive dependency (or any other pom configuration), you can
> have both the jars from the previous groupId and new groupId and with
> the same java package.
I see your "Maven hat" point ;-)
Having multiple versions of jclouds on the classpath usually causes
other problems independent of potential duplicate classes, though, so
I think even if we make a package change to avoid the duplicate
packages, people with multiple jclouds versions will still have
problems.
And if they need to avoid multiple jclouds versions on the classpath
anyway, this hopefully becomes at least less of a *practical* problem.
Do you have any suggestions for the 1.6.x and 1.5.x branches, where
the group ID change has also been applied?
* Make the package change here too (which seems a rather large
breaking change for a minor release)?
* Revert the group ID change?
* Stop releasing anything off the 1.6.x and 1.5.x branches?
* Other?
Suggestions appreciated!
Thanks
ap