You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jclouds.apache.org by Andrew Bayer <an...@gmail.com> on 2013/11/14 19:18:02 UTC
1.7.0 scheduling
So with 1.6.3 aiming to be out next week, I'd like to put a target date on
1.7.0 - we really need to get that sucker out! I'm gonna tentatively plan
to do the first RC on Monday, December 9th.
There are a fair number of issues still open against 1.7.0 - see
https://issues.apache.org/jira/browse/JCLOUDS-299?jql=project%20%3D%20JCLOUDS%20AND%20fixVersion%20%3D%20%221.7.0%22%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC
But I've created new 1.7.1 and 1.8.0 versions in JIRA (and 1.6.4, for that
matter), so we can move issues to those releases if appropriate (I just did
for a few, will go through the remaining issues in more detail later
today/tomorrow). It looks like the ones most likely not to get done for
1.7.0 are the remaining de-async related ones, and I'm fine with pushing
that off to 1.8.0.
Thoughts?
A.
Re: 1.7.0 scheduling
Posted by Andrew Bayer <an...@gmail.com>.
re [1] - I feel like it can, or at least *should*. I'll take a look
tomorrow...
A.
On Thu, Nov 14, 2013 at 5:55 PM, Andrew Phillips <ap...@qrmedia.com>wrote:
> That is something that could be useful, but if I am not wrong, we haven't
>> needed that yet.
>>
>
> I fear we actually need and use that every time we make a release, because
> of the way the projects are split across different repos and Maven "trees"
> :-(
>
> The problem we had for 1.6.2-incubating was as follows: at the start of a
> release, we first do the main jclouds repo, which results in a jclouds
> project POM version of X.Y.Z (no SNAPSHOT).
>
> The next release would be e.g. for jclouds-labs. If jclouds-labs inherits
> its version straight from jclouds-project, we have to leave jclouds-project
> at X.Y.Z-SNAPSHOT, because otherwise jclouds-labs is no longer a snapshot
> version and so can't be released [1].
>
> But we obviously want the released version of jclouds-labs to inherit from
> the *released* version of jclouds-project, so we need to set the
> jclouds-project dependency to X.Y.Z and keep the version of jclouds-labs at
> X.Y.Z-SNAPSHOT *ar the same time*.
>
> Then, if we run the release for jclouds-labs and it still has dependencies
> on snapshot core deps (which it will if they use ${project.version}, which
> is still a snapshot version), the release plugin prompts you 1,000,001
> times for the release version you want to use, which makes the release
> process really painful - at least, it was for 1.6.2-incubating.
>
> Setting the version of the parent POM and all the core deps to the release
> version in one commit seems much easier. If we can find a way to do that
> without a separate variable for the core dep version, all the better.
>
> Of course, if we find a way to get the Maven release plugin to "play nice"
> and handle all the version updates of deps outside the current reactor
> during the release, that would be ideal.
>
> ap
>
> [1] I don't know if the Maven release plugin can prompt you to update the
> *parent* POM version as it does for snapshot dependencies - we should check
> this!
>
Re: 1.7.0 scheduling
Posted by Andrew Phillips <ap...@qrmedia.com>.
> That is something that could be useful, but if I am not wrong, we
> haven't needed that yet.
I fear we actually need and use that every time we make a release,
because of the way the projects are split across different repos and
Maven "trees" :-(
The problem we had for 1.6.2-incubating was as follows: at the start
of a release, we first do the main jclouds repo, which results in a
jclouds project POM version of X.Y.Z (no SNAPSHOT).
The next release would be e.g. for jclouds-labs. If jclouds-labs
inherits its version straight from jclouds-project, we have to leave
jclouds-project at X.Y.Z-SNAPSHOT, because otherwise jclouds-labs is
no longer a snapshot version and so can't be released [1].
But we obviously want the released version of jclouds-labs to inherit
from the *released* version of jclouds-project, so we need to set the
jclouds-project dependency to X.Y.Z and keep the version of
jclouds-labs at X.Y.Z-SNAPSHOT *ar the same time*.
Then, if we run the release for jclouds-labs and it still has
dependencies on snapshot core deps (which it will if they use
${project.version}, which is still a snapshot version), the release
plugin prompts you 1,000,001 times for the release version you want to
use, which makes the release process really painful - at least, it was
for 1.6.2-incubating.
Setting the version of the parent POM and all the core deps to the
release version in one commit seems much easier. If we can find a way
to do that without a separate variable for the core dep version, all
the better.
Of course, if we find a way to get the Maven release plugin to "play
nice" and handle all the version updates of deps outside the current
reactor during the release, that would be ideal.
ap
[1] I don't know if the Maven release plugin can prompt you to update
the *parent* POM version as it does for snapshot dependencies - we
should check this!
Re: 1.7.0 scheduling
Posted by Ignasi <ig...@gmail.com>.
IMO 141 would be ideal. Using jclouds-project as the parent pom for
all projects would be ideal. That should allow us to remove the
"jclouds.version" property from all dependent projects and would make
the release process much simpler.
I think 104 deviated from its initial purpose and become an issue to
allow releasing the dependent projects independently from the main
jclouds repo. That is something that could be useful, but if I am not
wrong, we haven't needed that yet. So, if we can just implement 141
and make all repos inherit from jclouds-project, that would be great
to unify how dependencies are configured in all repos (considering we
always release all together).
If needed, we can later open an explicit issue to allow a more
fine-grained version configuration for the dependent modules, if we
find we need that.
WDYT?
On 14 November 2013 22:13, Zack Shoylev <za...@rackspace.com> wrote:
> Is there a short overview of what the current plan is? Is it 141?
> ________________________________________
> From: Andrew Bayer [andrew.bayer@gmail.com]
> Sent: Thursday, November 14, 2013 2:17 PM
> To: dev@jclouds.apache.org
> Subject: Re: 1.7.0 scheduling
>
> I believe you're talking about
> https://issues.apache.org/jira/browse/JCLOUDS-141 and
> https://issues.apache.org/jira/browse/JCLOUDS-104?
>
> A.
>
>
> On Thu, Nov 14, 2013 at 12:10 PM, Ignasi <ig...@gmail.com> wrote:
>
>> Sounds good to me.
>>
>> I'd really like to have the issue (don't remember the id) to configure the
>> versioning in the "sub-repos" completed for 1.7.
>>
>> It has been done in several repos but not in all of them (at least
>> jclouds-labs is still remaining), and I think it is important that we have
>> a consistent configuration in all pom.xml.
>>
>> Initially Zack had the issue assigned (do you think you'll have some time
>> to spend on it before releasing 1.7?) but I'll be happy to take it if
>> needed.
>> So with 1.6.3 aiming to be out next week, I'd like to put a target date on
>> 1.7.0 - we really need to get that sucker out! I'm gonna tentatively plan
>> to do the first RC on Monday, December 9th.
>>
>> There are a fair number of issues still open against 1.7.0 - see
>>
>> https://issues.apache.org/jira/browse/JCLOUDS-299?jql=project%20%3D%20JCLOUDS%20AND%20fixVersion%20%3D%20%221.7.0%22%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC
>>
>> But I've created new 1.7.1 and 1.8.0 versions in JIRA (and 1.6.4, for that
>> matter), so we can move issues to those releases if appropriate (I just did
>> for a few, will go through the remaining issues in more detail later
>> today/tomorrow). It looks like the ones most likely not to get done for
>> 1.7.0 are the remaining de-async related ones, and I'm fine with pushing
>> that off to 1.8.0.
>>
>> Thoughts?
>>
>> A.
>>
RE: 1.7.0 scheduling
Posted by Zack Shoylev <za...@RACKSPACE.COM>.
Is there a short overview of what the current plan is? Is it 141?
________________________________________
From: Andrew Bayer [andrew.bayer@gmail.com]
Sent: Thursday, November 14, 2013 2:17 PM
To: dev@jclouds.apache.org
Subject: Re: 1.7.0 scheduling
I believe you're talking about
https://issues.apache.org/jira/browse/JCLOUDS-141 and
https://issues.apache.org/jira/browse/JCLOUDS-104?
A.
On Thu, Nov 14, 2013 at 12:10 PM, Ignasi <ig...@gmail.com> wrote:
> Sounds good to me.
>
> I'd really like to have the issue (don't remember the id) to configure the
> versioning in the "sub-repos" completed for 1.7.
>
> It has been done in several repos but not in all of them (at least
> jclouds-labs is still remaining), and I think it is important that we have
> a consistent configuration in all pom.xml.
>
> Initially Zack had the issue assigned (do you think you'll have some time
> to spend on it before releasing 1.7?) but I'll be happy to take it if
> needed.
> So with 1.6.3 aiming to be out next week, I'd like to put a target date on
> 1.7.0 - we really need to get that sucker out! I'm gonna tentatively plan
> to do the first RC on Monday, December 9th.
>
> There are a fair number of issues still open against 1.7.0 - see
>
> https://issues.apache.org/jira/browse/JCLOUDS-299?jql=project%20%3D%20JCLOUDS%20AND%20fixVersion%20%3D%20%221.7.0%22%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC
>
> But I've created new 1.7.1 and 1.8.0 versions in JIRA (and 1.6.4, for that
> matter), so we can move issues to those releases if appropriate (I just did
> for a few, will go through the remaining issues in more detail later
> today/tomorrow). It looks like the ones most likely not to get done for
> 1.7.0 are the remaining de-async related ones, and I'm fine with pushing
> that off to 1.8.0.
>
> Thoughts?
>
> A.
>
Re: 1.7.0 scheduling
Posted by Andrew Bayer <an...@gmail.com>.
I believe you're talking about
https://issues.apache.org/jira/browse/JCLOUDS-141 and
https://issues.apache.org/jira/browse/JCLOUDS-104?
A.
On Thu, Nov 14, 2013 at 12:10 PM, Ignasi <ig...@gmail.com> wrote:
> Sounds good to me.
>
> I'd really like to have the issue (don't remember the id) to configure the
> versioning in the "sub-repos" completed for 1.7.
>
> It has been done in several repos but not in all of them (at least
> jclouds-labs is still remaining), and I think it is important that we have
> a consistent configuration in all pom.xml.
>
> Initially Zack had the issue assigned (do you think you'll have some time
> to spend on it before releasing 1.7?) but I'll be happy to take it if
> needed.
> So with 1.6.3 aiming to be out next week, I'd like to put a target date on
> 1.7.0 - we really need to get that sucker out! I'm gonna tentatively plan
> to do the first RC on Monday, December 9th.
>
> There are a fair number of issues still open against 1.7.0 - see
>
> https://issues.apache.org/jira/browse/JCLOUDS-299?jql=project%20%3D%20JCLOUDS%20AND%20fixVersion%20%3D%20%221.7.0%22%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC
>
> But I've created new 1.7.1 and 1.8.0 versions in JIRA (and 1.6.4, for that
> matter), so we can move issues to those releases if appropriate (I just did
> for a few, will go through the remaining issues in more detail later
> today/tomorrow). It looks like the ones most likely not to get done for
> 1.7.0 are the remaining de-async related ones, and I'm fine with pushing
> that off to 1.8.0.
>
> Thoughts?
>
> A.
>
Re: 1.7.0 scheduling
Posted by Ignasi <ig...@gmail.com>.
Sounds good to me.
I'd really like to have the issue (don't remember the id) to configure the
versioning in the "sub-repos" completed for 1.7.
It has been done in several repos but not in all of them (at least
jclouds-labs is still remaining), and I think it is important that we have
a consistent configuration in all pom.xml.
Initially Zack had the issue assigned (do you think you'll have some time
to spend on it before releasing 1.7?) but I'll be happy to take it if
needed.
So with 1.6.3 aiming to be out next week, I'd like to put a target date on
1.7.0 - we really need to get that sucker out! I'm gonna tentatively plan
to do the first RC on Monday, December 9th.
There are a fair number of issues still open against 1.7.0 - see
https://issues.apache.org/jira/browse/JCLOUDS-299?jql=project%20%3D%20JCLOUDS%20AND%20fixVersion%20%3D%20%221.7.0%22%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC
But I've created new 1.7.1 and 1.8.0 versions in JIRA (and 1.6.4, for that
matter), so we can move issues to those releases if appropriate (I just did
for a few, will go through the remaining issues in more detail later
today/tomorrow). It looks like the ones most likely not to get done for
1.7.0 are the remaining de-async related ones, and I'm fine with pushing
that off to 1.8.0.
Thoughts?
A.
Re: 1.7.0 scheduling
Posted by Andrew Bayer <an...@gmail.com>.
No on all counts, IMO. If we run into problems with 1.7.0, well, then we
release 1.7.1. I'm not a fan of the alpha/beta thing. I'm also averse to
the package rename - we're a little late in the game to consider that, and
it's such a massive compatibility-breaking change that I'd rather due that
in 2.0. And I'm not opposed to moving jclouds-chef into the main repo, but
again, not this late in the game - the goal at this point should be to get
1.7.0 out ASAP, so major architectural/code layout/etc issues should be
deferred, I thinkk.
A.
On Wed, Nov 20, 2013 at 10:15 AM, Andrew Gaul <ga...@apache.org> wrote:
> On Thu, Nov 14, 2013 at 10:18:02AM -0800, Andrew Bayer wrote:
> > So with 1.6.3 aiming to be out next week, I'd like to put a target date
> on
> > 1.7.0 - we really need to get that sucker out! I'm gonna tentatively plan
> > to do the first RC on Monday, December 9th.
> >
> > There are a fair number of issues still open against 1.7.0 - see
> >
> https://issues.apache.org/jira/browse/JCLOUDS-299?jql=project%20%3D%20JCLOUDS%20AND%20fixVersion%20%3D%20%221.7.0%22%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC
> >
> > But I've created new 1.7.1 and 1.8.0 versions in JIRA (and 1.6.4, for
> that
> > matter), so we can move issues to those releases if appropriate (I just
> did
> > for a few, will go through the remaining issues in more detail later
> > today/tomorrow). It looks like the ones most likely not to get done for
> > 1.7.0 are the remaining de-async related ones, and I'm fine with pushing
> > that off to 1.8.0.
> >
> > Thoughts?
>
> I prefer to release 1.7 sooner rather than later. Three thoughts for
> 1.7:
>
> Should we publish 1.7 alpha/beta artifacts like we did pre-ASF? Ideally
> we would have done this regularly during the 1.7 development cycle.
>
> Should we mass-rename packages from org.jclouds to org.apache.jclouds?
> Doing this now might prove easier for users than deferring the
> migration.
>
> Should we should bring jclouds-chef into the main repository to simplify
> our repositories? This currently adds an extra step while releasing.
>
> --
> Andrew Gaul
> http://gaul.org/
>
Re: 1.7.0 scheduling
Posted by Ignasi <ig...@gmail.com>.
+1 to release as soon as possible.
As discussed in the other thread, I also think the package rename
should be delayed until 2.0.
Regarding the Chef thing, I am open to whatever is preferred. It is
very stable and can be merged without issues in the main repo, but I
don't think this should be a priority or a must. Can be perfectly done
in 1.7.2 or even in a later release if that helps cut 1.7.0 sooner.
On 20 November 2013 19:53, Andrew Phillips <ap...@qrmedia.com> wrote:
>>> Should we publish 1.7 alpha/beta artifacts like we did pre-ASF? Ideally
>>> we would have done this regularly during the 1.7 development cycle.
>
> ...
>
>> Would work for me - they've been stable for ages, see active use and
>> improvements and don't feel significantly less generic that e.g.
>> route53.
>>
>> ap
>
>
> I should add that I agree with abayer's point that these don't have to be
> done if they risk significantly delaying 1.7. I wasn't trying to imply that
> we should do the jclouds-chef thing - if we do it - *now*.
>
> ap
Re: 1.7.0 scheduling
Posted by Andrew Phillips <ap...@qrmedia.com>.
>> Should we publish 1.7 alpha/beta artifacts like we did pre-ASF? Ideally
>> we would have done this regularly during the 1.7 development cycle.
...
> Would work for me - they've been stable for ages, see active use and
> improvements and don't feel significantly less generic that e.g.
> route53.
>
> ap
I should add that I agree with abayer's point that these don't have to
be done if they risk significantly delaying 1.7. I wasn't trying to
imply that we should do the jclouds-chef thing - if we do it - *now*.
ap
Re: 1.7.0 scheduling
Posted by Andrew Phillips <ap...@qrmedia.com>.
> Should we publish 1.7 alpha/beta artifacts like we did pre-ASF? Ideally
> we would have done this regularly during the 1.7 development cycle.
If we can find a way to do this reasonably quickly (ideally,
automatically!) I'm sure that would help. As it is (hope it's been
smooth for you, Andrew G!), releasing so far has taken a bit too long,
in my opinion, to consider this.
> Should we mass-rename packages from org.jclouds to org.apache.jclouds?
> Doing this now might prove easier for users than deferring the
> migration.
I think there was already a thread discussing this somewhere. I'd
personally prefer a significant breaking change such as this to be a
2.0 thing. But if we feel that will still be a while off, or if we
need to do that sooner from an ASF perspective, then it's a bullet
we'll just have to bite.
I liked Adrian's suggestion of trying to find a way to avoid a
migration effort for users that is both a big rename *and* some
significant functionality changes/deprecation, as we're going to be
doing for 1.7 and 1.8 with de-async etc.
> Should we should bring jclouds-chef into the main repository to simplify
> our repositories? This currently adds an extra step while releasing.
Would work for me - they've been stable for ages, see active use and
improvements and don't feel significantly less generic that e.g.
route53.
ap
Re: 1.7.0 scheduling
Posted by Andrew Gaul <ga...@apache.org>.
On Thu, Nov 14, 2013 at 10:18:02AM -0800, Andrew Bayer wrote:
> So with 1.6.3 aiming to be out next week, I'd like to put a target date on
> 1.7.0 - we really need to get that sucker out! I'm gonna tentatively plan
> to do the first RC on Monday, December 9th.
>
> There are a fair number of issues still open against 1.7.0 - see
> https://issues.apache.org/jira/browse/JCLOUDS-299?jql=project%20%3D%20JCLOUDS%20AND%20fixVersion%20%3D%20%221.7.0%22%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC
>
> But I've created new 1.7.1 and 1.8.0 versions in JIRA (and 1.6.4, for that
> matter), so we can move issues to those releases if appropriate (I just did
> for a few, will go through the remaining issues in more detail later
> today/tomorrow). It looks like the ones most likely not to get done for
> 1.7.0 are the remaining de-async related ones, and I'm fine with pushing
> that off to 1.8.0.
>
> Thoughts?
I prefer to release 1.7 sooner rather than later. Three thoughts for
1.7:
Should we publish 1.7 alpha/beta artifacts like we did pre-ASF? Ideally
we would have done this regularly during the 1.7 development cycle.
Should we mass-rename packages from org.jclouds to org.apache.jclouds?
Doing this now might prove easier for users than deferring the
migration.
Should we should bring jclouds-chef into the main repository to simplify
our repositories? This currently adds an extra step while releasing.
--
Andrew Gaul
http://gaul.org/
Re: 1.7.0 scheduling
Posted by Andrew Bayer <an...@gmail.com>.
Yeah, I missed a curly brace. =)
On Wed, Nov 20, 2013 at 10:14 AM, Andrew Phillips <ap...@qrmedia.com>wrote:
> Yup, mentioned in the wiki.
>>
>
> Doh, sloppy reading, sorry. It didn't render properly for me, I think (see
> attachment) - should be fixed now [1]?
>
> ap
>
> [1] https://wiki.apache.org/jclouds/Releasing%20jclouds?
> action=diff&rev1=27&rev2=28
>
Re: 1.7.0 scheduling
Posted by Andrew Phillips <ap...@qrmedia.com>.
> Yup, mentioned in the wiki.
Doh, sloppy reading, sorry. It didn't render properly for me, I think
(see attachment) - should be fixed now [1]?
ap
[1]
https://wiki.apache.org/jclouds/Releasing%20jclouds?action=diff&rev1=27&rev2=28
Re: 1.7.0 scheduling
Posted by Andrew Bayer <an...@gmail.com>.
Yup, mentioned in the wiki.
A.
On Tue, Nov 19, 2013 at 9:29 PM, Andrew Phillips <ap...@qrmedia.com>wrote:
> Just did a bit of cleanup on the 1.6.x branch of jclouds-labs-openstack to
>> get its versioning in a sane way - turns out the sane way was already in
>> place for 1.7.0 there, so woo. Checking the others now, but I think we're
>> ok with an extra step I specified on the release process wiki.
>>
>
> Do we need some kind of "compensating command" to the mvn
> versions:update-parent invocation, to go back to the next snapshot parent
> *after* the release?
>
> ap
>
Re: 1.7.0 scheduling
Posted by Andrew Phillips <ap...@qrmedia.com>.
> Just did a bit of cleanup on the 1.6.x branch of jclouds-labs-openstack to
> get its versioning in a sane way - turns out the sane way was already in
> place for 1.7.0 there, so woo. Checking the others now, but I think we're
> ok with an extra step I specified on the release process wiki.
Do we need some kind of "compensating command" to the mvn
versions:update-parent invocation, to go back to the next snapshot
parent *after* the release?
ap
Re: 1.7.0 scheduling
Posted by Andrew Bayer <an...@gmail.com>.
Just did a bit of cleanup on the 1.6.x branch of jclouds-labs-openstack to
get its versioning in a sane way - turns out the sane way was already in
place for 1.7.0 there, so woo. Checking the others now, but I think we're
ok with an extra step I specified on the release process wiki.
A.
On Fri, Nov 15, 2013 at 9:05 AM, Alex Heneveld <
alex.heneveld@cloudsoftcorp.com> wrote:
> +1
>
> Best,
> Alex
> On Nov 15, 2013 4:22 PM, "Everett Toews" <ev...@rackspace.com>
> wrote:
>
> > On Nov 14, 2013, at 12:18 PM, Andrew Bayer wrote:
> >
> > > So with 1.6.3 aiming to be out next week, I'd like to put a target date
> > on
> > > 1.7.0 - we really need to get that sucker out! I'm gonna tentatively
> plan
> > > to do the first RC on Monday, December 9th.
> >
> > +1
> >
> > Everett
> >
>
Re: 1.7.0 scheduling
Posted by Alex Heneveld <al...@cloudsoftcorp.com>.
+1
Best,
Alex
On Nov 15, 2013 4:22 PM, "Everett Toews" <ev...@rackspace.com>
wrote:
> On Nov 14, 2013, at 12:18 PM, Andrew Bayer wrote:
>
> > So with 1.6.3 aiming to be out next week, I'd like to put a target date
> on
> > 1.7.0 - we really need to get that sucker out! I'm gonna tentatively plan
> > to do the first RC on Monday, December 9th.
>
> +1
>
> Everett
>
Re: 1.7.0 scheduling
Posted by Everett Toews <ev...@RACKSPACE.COM>.
On Nov 14, 2013, at 12:18 PM, Andrew Bayer wrote:
> So with 1.6.3 aiming to be out next week, I'd like to put a target date on
> 1.7.0 - we really need to get that sucker out! I'm gonna tentatively plan
> to do the first RC on Monday, December 9th.
+1
Everett