You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@brooklyn.apache.org by Hadrian Zbarcea <hz...@gmail.com> on 2015/07/14 04:40:30 UTC
Re: No 0.7.0-rc1 release today :(
My proposed changes to unblock the release are now complete [1]. They
are done however on the master, which leaves us with one of the
following options (if I am not missing something)
1. Backport to a 0.7.0-Mxxx branch
2. Abandon 0.7.0-Mxxx and release at 0.8.0
While either work, I somewhat prefer moving on with #2 as the simplest
solution.
Another thought is that migrating packages from brooklyn.* to
org.apache.brooklyn.* will be necessary at some point. I suspect best
would be to do it now before a release.
Thoughts?
Hadrian
[1] https://github.com/apache/incubator-brooklyn/pull/737
On 06/27/2015 09:09 PM, Hadrian Zbarcea wrote:
> This is not an easy one and imho would require some community choice
> before implementing a solution.
>
> 1. To be able to release downstream-parent, it would have to have the
> proper configuration, specifically for the release and gpg maven
> plugins, that comes actually from the org.apache:apache:17 parent.
> 2. Consequently, the downstream parent should have either
> org.apache:apache:17 or even better org.apache.brooklyn:brooklyn-parent
> as a parent.
> 3. The downstream-parent is only used in the quickstart archetype.
>
> There is questionable value in having a downstream-parent that users
> would have to change anyway if it caries the apache scp and release
> configurations that wouldn't apply for a user's project.
>
> The only 2 solutions I can think of are to:
> a. Get rid of the downstream parent and move all the necessary
> incantations in the quickstart archetype.
> b. Transform the downstream-parent (and maybe come up with a better name
> for it) into a <scope>import</scope> pom [1].
>
> I think this is a blocker for the release.
>
> Thoughts?
> Hadrian
>
> [1]
> https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Importing_Dependencies
>
>
> On 06/27/2015 04:05 AM, Andrea Turli wrote:
>> Thanks Hadrian,
>>
>> I've also found this one while googling for another project [1], so
>> either
>> Apache parent or nothing should fix the issue.
>>
>> HTH,
>> Andrea
>>
>> [1]:
>> http://central.sonatype.org/pages/apache-maven.html#deprecated-oss-parent
>>
>> On Sat, 27 Jun 2015 at 05:58 Hadrian Zbarcea <hz...@gmail.com> wrote:
>>
>>> First thing, the <parent> for the brooklyn-downstream-parent should
>>> not be:
>>> <parent>
>>> <groupId>org.sonatype.oss</groupId>
>>> <artifactId>oss-parent</artifactId>
>>> <version>9</version>
>>> </parent>
>>>
>>> but the apache parent ultimately. I think this should completely resolve
>>> the problem. It's a bit late here to test, I'll do it tomorrow.
>>>
>>> Cheers,
>>> Hadrian
>>>
>>>
>>> On 06/26/2015 11:35 PM, Hadrian Zbarcea wrote:
>>>> I did try a dryRun myself and did encounter a problem with the
>>>> brooklyn-downstream-parent, but of a different nature
>>>> "'parent.relativePath' points at wrong local POM", but I suspect there
>>>> more issues there. From my experience releasing other projects, I
>>>> try to
>>>> first remove relevant branches from my local maven repo before
>>>> preparing
>>>> a release.
>>>>
>>>> I will look at it during the weekend. Somebody should revert the
>>>> version
>>>> back from 0.8.0-SNAPSHOT though.
>>>>
>>>> Cheers,
>>>> Hadrian
>>>>
>>>> On 06/26/2015 04:53 PM, Richard Downer wrote:
>>>>> So we got all the source code lined up today, and the release branch
>>>>> made.
>>>>> Everything was going very promisingly until I tried to close the Nexus
>>>>> repository to publish the artifacts and got a rule violation error.
>>>>>
>>>>> I'll have a look at fixing the problem and re-starting the release on
>>>>> Monday (unfortunately I won't have any availability to look at this
>>>>> over
>>>>> the weekend).
>>>>>
>>>>> In the meantime if anyone is looking for something to do over the
>>>>> weekend,
>>>>> the exact failure Nexus reported was:
>>>>>
>>>>> Missing Signature:
>>>>>
>>> '/org/apache/brooklyn/brooklyn-downstream-parent/0.7.0-incubating/brooklyn-downstream-parent-0.7.0-incubating.pom.asc'
>>>
>>>>>
>>>>> does not exist for 'brooklyn-downstream-parent-0.7.0-incubating.pom'.
>>>>>
>>>>> Everything else has a .pom.asc except downstream-parent so it seems
>>>>> there's
>>>>> something special about this project.
>>>>>
>>>>> Richard.
>>>>>
>>>
>>
Re: No 0.7.0-rc1 release today :(
Posted by Ciprian Ciubotariu <ch...@gmx.net>.
Hi!
Thank you for your comments.
For #1, I don't think it's realistic to expect the PR queue to get empty.
I have started a branch with a stream of commits that performs rename on each
project in the reverse order of the maven reactor build (i.e. starting with
the "leafs"). These commits can be applied selectively, depending on how hot
is the repository in that area.
For #3 I agree with Hadrian. Using class names within YAML has the advantages
of being convenient and straightforward, since the resolution is actually
performed by the JVM classloader. However, it does bring the limitations of
the classloader in brooklyn's API, and it is the publication of those class
names in the API that makes renaming them a problem.
For the specific purpose of package renaming I would opt for maintaining a
compatibility layer, having a new project of brooklyn.* classes annotate an
indirection towards the renamed org.apache.brooklyn.* classes. When resolving
this indirection we could issue a deprecation warning in the logs until we
decide to move to a new system (which should be a larger discussion).
How does this sound to you?
Ciprian
On Tuesday 14 July 2015 11:11:43 Hadrian Zbarcea wrote:
> Hi Aled,
>
> All good points.
>
> 1. Ideally, the PR queue should be emtpy.
> 2. Good question. However I assume there will be enough time to iron out
> the snags before the next release. The best time to start this is
> probably right after a release (0.7 or 0.8)
> 3. Would it be possible to have an (optional) migration catalogue/map
> for entity names?
>
> Actually your point #3 is interesting. I was talking to some guys a
> while ago about using URIs (URN) or something instead of the confusing
> class names, kinda like:
>
> name: simple-appserver
> location: localhost
> services:
> - type: brooklyn:.webapp:0.7.0:JBoss7Server
>
> instead of:
> - type: brooklyn.entity.webapp.jboss.JBoss7Server
>
> ... which would resolve to the appropriate class. That is introducing a
> resolution mechanism.
>
> Hadrian
>
> On 07/14/2015 08:26 AM, Aled Sage wrote:
> > Hi, thanks for that.
> >
> > I'd like us to treat this with caution for when we make the change. For
> > example:
> >
> > 1. All open PRs will likely be affected (i.e. potentially needing
> >
> > significant rebasing).
> >
> > 2. Are our regression tests good enough, particularly with the impact
> >
> > on persisted state.
> > Any improvements to do first?
> >
> > 3. What backwards compatibility guarantees do we want to give, e.g. of
> >
> > fully qualified names used in YAML blueprints.
> >
> > We should have a think about (2) and (3), to ensure we do the right prep
> > before the rename.
> >
> > ---
> > I hope that the refactor can be done relatively quickly in a modern IDE.
> > (And searching the *.yaml files). Assuming that is true, then it may be
> > worth doing a *dry run* and seeing what tests etc fail. Those could
> > either be improved in the existing master (i.e. before the rename) so
> > that they won't fail, or just note the required fixes so that we can do
> > it quickly.
> >
> > We then may be able to plan ahead, to say that the rename will be done
> > on a particular day. We could aim to merge other PRs before that, and
> > everyone would know to expect major merge conflicts for anything we did
> > that particular day.
> >
> > Does that seem feasible/sensible?!
> >
> > ---
> > I also propose we change to 1.0.0-SNAPSHOT in preparation for all of the
> > renames.
> >
> > I'll propose that again in a separate e-mail thread for discussion, as
> > this one is already diverging from its original subject!
> >
> > Aled
> >
> > On 14/07/2015 12:59, Ciprian Ciubotariu wrote:
> >> I can start working on the package rename on a fork of the master branch,
> >> which can be rebased when integrating pending PRs. If we integrate
> >> this branch
> >> often back into master we can avoid blocking development.
> >>
> >> On Tuesday 14 July 2015 10:07:30 Aled Sage wrote:
> >>> +1 for changing package name *after* the 0.7.0 release.
> >>>
> >>> I propose:
> >>> * Release 0.7.0 with the existing package name
> >>>
> >>> (so that users have a stable (not milestone) release that they can
> >>> use with confidence with minimal effort).
> >>>
> >>> * Work towards a 1.0:
> >>> o clear any PR backlog
> >>> o change the package names in master
> >>> o document and thoroughly test the upgrade process from 0.7.0
> >>>
> >>> to 1.0
> >>>
> >>> (explicitly *not* support any other upgrade paths, such as
> >>> 0.7.0-M2 to 1.0, etc)
> >>>
> >>> o see what other features / fixes the community demand/want in a
> >>>
> >>> 1.0 release.
> >>>
> >>> ---
> >>> For version number, I also favour sticking with 0.7.0.
> >>>
> >>> Of the two options for that:
> >>> 1. backport changes to the 0.7.x branch, or
> >>> 2. delete + recreate that to incorporate all code that is currently in
> >>>
> >>> master, but reverting version number to 0.7.0...
> >>>
> >>> I prefer the backport option, if that's not too hard technically.
> >>>
> >>> Aled
> >>>
> >>> On 14/07/2015 09:13, Richard Downer wrote:
> >>>> On the subject of changing the Java package name (which I forgot to
> >>>> mention) - yes this is something that will need to be done and we have
> >>>> discussed this previously. The decisions was that the in-development
> >>>> version of 0.7.0 would *not* have this change, but that it would be
> >>>> done
> >>>> for 0.8.0.
> >>>>
> >>>> 0.7.0 has been brewing for a long time and I don't think there's the
> >>>> appetite to do this right now. It's a major change, it would break our
> >>>> user's code (which would be unfair on those that have been using
> >>>> 0.7.0-M2)
> >>>> and I've no doubt it would take weeks to fully shake out all the
> >>>> bugs from
> >>>> that kind of change. Meanwhile our users are clamouring for a 0.7.0
> >>>> release as soon as we can :-)
> >>>>
> >>>> Once we've got 0.7.0 released then we'll kick off 0.8.0 development
> >>>> proper
> >>>> and have a discussion about what changes we want to include.
> >>>>
> >>>> Richard.
> >>>>
> >>>> On Tue, 14 Jul 2015 at 09:03 Richard Downer <ri...@apache.org> wrote:
> >>>>> Hadrian, thanks very much for your efforts on this release blocker.
> >>>>>
> >>>>> I'm now back from vacation - I think that Sam is very busy this
> >>>>> week so
> >>>>> I'll put the Release Manager hat back on again and get an rc1 done
> >>>>> today.
> >>>>>
> >>>>> Along with Svet I'm also in favour of option 1 - we have a release
> >>>>> branch
> >>>>> ready and we've already prepped some downstream customers to
> >>>>> prepare for
> >>>>> 0.7.0-final, so I'm not keen to change the version. I'm assuming that
> >>>>> apart
> >>>>> from the 0.7.0/0.8.0 difference, your changes should backport
> >>>>> cleanly to
> >>>>> the release branch.
> >>>>>
> >>>>> Should I be mistaken about the difficulty of this, then I will
> >>>>> change my
> >>>>> mind :-)
> >>>>>
> >>>>> Thanks again Hadrian and everyone else who has been looking at this
> >>>>> problem.
> >>>>>
> >>>>> Richard.
> >>>>>
> >>>>>
> >>>>> On Tue, 14 Jul 2015 at 08:58 Svetoslav Neykov <
> >>>>>
> >>>>> svetoslav.neykov@cloudsoftcorp.com> wrote:
> >>>>>> I am for 1). As far as I know there's already a release branch
> >>>>>> with some
> >>>>>> backports. Another option is:
> >>>>>>
> >>>>>> 3. Create a 0.7.0 release off of the current master by changing
> >>>>>> back the
> >>>>>> version.
> >>>>>>
> >>>>>> Changing the package name should be done sooner rather than later,
> >>>>>> but
> >>>>>>
> >>>>>> requires *very* careful planning due to:
> >>>>>> * The need to keep backwards compatibility for existing
> >>>>>>
> >>>>>> persistence
> >>>>>>
> >>>>>> stores. I'd prefer to have
> >>>>>> https://github.com/apache/incubator-brooklyn/pull/738 <
> >>>>>> https://github.com/apache/incubator-brooklyn/pull/738> merged before
> >>>>>> attempting it.
> >>>>>>
> >>>>>> * Existing 3rd party blueprints better still be usable after the
> >>>>>>
> >>>>>> change, though this doesn't seem possible.
> >>>>>>
> >>>>>> Svet.
> >>>>>>
> >>>>>>> On 14.07.2015 г., at 5:40, Hadrian Zbarcea <hz...@gmail.com>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>> My proposed changes to unblock the release are now complete [1].
> >>>>>>> They
> >>>>>>
> >>>>>> are done however on the master, which leaves us with one of the
> >>>>>> following
> >>>>>> options (if I am not missing something)
> >>>>>>
> >>>>>>> 1. Backport to a 0.7.0-Mxxx branch
> >>>>>>> 2. Abandon 0.7.0-Mxxx and release at 0.8.0
> >>>>>>>
> >>>>>>> While either work, I somewhat prefer moving on with #2 as the
> >>>>>>> simplest
> >>>>>>
> >>>>>> solution.
> >>>>>>
> >>>>>>> Another thought is that migrating packages from brooklyn.* to
> >>>>>>
> >>>>>> org.apache.brooklyn.* will be necessary at some point. I suspect best
> >>>>>> would
> >>>>>> be to do it now before a release.
> >>>>>>
> >>>>>>> Thoughts?
> >>>>>>> Hadrian
> >>>>>>>
> >>>>>>> [1] https://github.com/apache/incubator-brooklyn/pull/737
> >>>>>>>
> >>>>>>> On 06/27/2015 09:09 PM, Hadrian Zbarcea wrote:
> >>>>>>>> This is not an easy one and imho would require some community
> >>>>>>>> choice
> >>>>>>>> before implementing a solution.
> >>>>>>>>
> >>>>>>>> 1. To be able to release downstream-parent, it would have to
> >>>>>>>> have the
> >>>>>>>> proper configuration, specifically for the release and gpg maven
> >>>>>>>> plugins, that comes actually from the org.apache:apache:17 parent.
> >>>>>>>> 2. Consequently, the downstream parent should have either
> >>>>>>>> org.apache:apache:17 or even better
> >>>>>>>> org.apache.brooklyn:brooklyn-parent
> >>>>>>>> as a parent.
> >>>>>>>> 3. The downstream-parent is only used in the quickstart archetype.
> >>>>>>>>
> >>>>>>>> There is questionable value in having a downstream-parent that
> >>>>>>>> users
> >>>>>>>> would have to change anyway if it caries the apache scp and release
> >>>>>>>> configurations that wouldn't apply for a user's project.
> >>>>>>>>
> >>>>>>>> The only 2 solutions I can think of are to:
> >>>>>>>> a. Get rid of the downstream parent and move all the necessary
> >>>>>>>> incantations in the quickstart archetype.
> >>>>>>>> b. Transform the downstream-parent (and maybe come up with a better
> >>>>>>
> >>>>>> name
> >>>>>>
> >>>>>>>> for it) into a <scope>import</scope> pom [1].
> >>>>>>>>
> >>>>>>>> I think this is a blocker for the release.
> >>>>>>>>
> >>>>>>>> Thoughts?
> >>>>>>>> Hadrian
> >>>>>>>>
> >>>>>>>> [1]
> >>>>>>
> >>>>>> https://maven.apache.org/guides/introduction/introduction-to-dependen
> >>>>>> cy->
> >>>>>>
> >>>>>> >>> mechanism.html#Importing_Dependencies>>>
> >>>>>>>>
> >>>>>>>> On 06/27/2015 04:05 AM, Andrea Turli wrote:
> >>>>>>>>> Thanks Hadrian,
> >>>>>>>>>
> >>>>>>>>> I've also found this one while googling for another project
> >>>>>>>>> [1], so
> >>>>>>>>> either
> >>>>>>>>> Apache parent or nothing should fix the issue.
> >>>>>>>>>
> >>>>>>>>> HTH,
> >>>>>>>>> Andrea
> >>>>>>
> >>>>>>>>> [1]:
> >>>>>> http://central.sonatype.org/pages/apache-maven.html#deprecated-oss-pa
> >>>>>> ren
> >>>>>>
> >>>>>> t
> >>>>>>
> >>>>>>>>> On Sat, 27 Jun 2015 at 05:58 Hadrian Zbarcea <hz...@gmail.com>
> >>>>>>
> >>>>>> wrote:
> >>>>>>>>>> First thing, the <parent> for the brooklyn-downstream-parent
> >>>>>>>>>> should
> >>>>>>>>>>
> >>>>>>>>>> not be:
> >>>>>>>>>> <parent>
> >>>>>>>>>>
> >>>>>>>>>> <groupId>org.sonatype.oss</groupId>
> >>>>>>>>>> <artifactId>oss-parent</artifactId>
> >>>>>>>>>> <version>9</version>
> >>>>>>>>>>
> >>>>>>>>>> </parent>
> >>>>>>>>>>
> >>>>>>>>>> but the apache parent ultimately. I think this should completely
> >>>>>>
> >>>>>> resolve
> >>>>>>
> >>>>>>>>>> the problem. It's a bit late here to test, I'll do it tomorrow.
> >>>>>>>>>>
> >>>>>>>>>> Cheers,
> >>>>>>>>>> Hadrian
> >>>>>>>>>>
> >>>>>>>>>> On 06/26/2015 11:35 PM, Hadrian Zbarcea wrote:
> >>>>>>>>>>> I did try a dryRun myself and did encounter a problem with the
> >>>>>>>>>>> brooklyn-downstream-parent, but of a different nature
> >>>>>>>>>>> "'parent.relativePath' points at wrong local POM", but I suspect
> >>>>>>
> >>>>>> there
> >>>>>>
> >>>>>>>>>>> more issues there. From my experience releasing other
> >>>>>>>>>>> projects, I
> >>>>>>>>>>> try to
> >>>>>>>>>>> first remove relevant branches from my local maven repo before
> >>>>>>>>>>> preparing
> >>>>>>>>>>> a release.
> >>>>>>>>>>>
> >>>>>>>>>>> I will look at it during the weekend. Somebody should revert the
> >>>>>>>>>>> version
> >>>>>>>>>>> back from 0.8.0-SNAPSHOT though.
> >>>>>>>>>>>
> >>>>>>>>>>> Cheers,
> >>>>>>>>>>> Hadrian
> >>>>>>>>>>>
> >>>>>>>>>>> On 06/26/2015 04:53 PM, Richard Downer wrote:
> >>>>>>>>>>>> So we got all the source code lined up today, and the release
> >>>>>>
> >>>>>> branch
> >>>>>>
> >>>>>>>>>>>> made.
> >>>>>>>>>>>> Everything was going very promisingly until I tried to close
> >>>>>>>>>>>> the
> >>>>>>
> >>>>>> Nexus
> >>>>>>
> >>>>>>>>>>>> repository to publish the artifacts and got a rule violation
> >>>>>>>>>>>> error.
> >>>>>>>>>>>>
> >>>>>>>>>>>> I'll have a look at fixing the problem and re-starting the
> >>>>>>>>>>>> release
> >>>>>>
> >>>>>> on
> >>>>>>
> >>>>>>>>>>>> Monday (unfortunately I won't have any availability to look at
> >>>>>>>>>>>> this
> >>>>>>>>>>>> over
> >>>>>>>>>>>> the weekend).
> >>>>>>>>>>>>
> >>>>>>>>>>>> In the meantime if anyone is looking for something to do
> >>>>>>>>>>>> over the
> >>>>>>>>>>>> weekend,
> >>>>>>>>>>>> the exact failure Nexus reported was:
> >>>>>>
> >>>>>>>>>>>> Missing Signature:
> >>>>>> '/org/apache/brooklyn/brooklyn-downstream-parent/0.7.0-incubating/bro
> >>>>>> okl
> >>>>>>
> >>>>>> yn-downstream-parent-0.7.0-incubating.pom.asc'>>>
> >>>>>>
> >>>>>>>>>>>> does not exist for
> >>>>>>
> >>>>>> 'brooklyn-downstream-parent-0.7.0-incubating.pom'.
> >>>>>>
> >>>>>>>>>>>> Everything else has a .pom.asc except downstream-parent so it
> >>>>>>>>>>>> seems
> >>>>>>>>>>>> there's
> >>>>>>>>>>>> something special about this project.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Richard.
> >>>>>>
> >>>>>> --
> >>>>>> Cloudsoft Corporation Limited, Registered in Scotland No: SC349230.
> >>>>>>
> >>>>>> Registered Office: 13 Dryden Place, Edinburgh, EH9 1RP
> >>>>>>
> >>>>>> This e-mail message is confidential and for use by the addressee
> >>>>>> only.
> >>>>>> If
> >>>>>> the message is received by anyone other than the addressee, please
> >>>>>> return
> >>>>>> the message to the sender by replying to it and then delete the
> >>>>>> message
> >>>>>> from your computer. Internet e-mails are not necessarily secure.
> >>>>>> Cloudsoft
> >>>>>> Corporation Limited does not accept responsibility for changes
> >>>>>> made to
> >>>>>> this
> >>>>>> message after it was sent.
> >>>>>>
> >>>>>> Whilst all reasonable care has been taken to avoid the
> >>>>>> transmission of
> >>>>>> viruses, it is the responsibility of the recipient to ensure that the
> >>>>>> onward transmission, opening or use of this message and any
> >>>>>> attachments
> >>>>>> will not adversely affect its systems or data. No responsibility is
> >>>>>> accepted by Cloudsoft Corporation Limited in this regard and the
> >>>>>> recipient
> >>>>>> should carry out such virus and other checks as it considers
> >>>>>> appropriate.
Re: No 0.7.0-rc1 release today :(
Posted by Hadrian Zbarcea <hz...@gmail.com>.
Hi Aled,
All good points.
1. Ideally, the PR queue should be emtpy.
2. Good question. However I assume there will be enough time to iron out
the snags before the next release. The best time to start this is
probably right after a release (0.7 or 0.8)
3. Would it be possible to have an (optional) migration catalogue/map
for entity names?
Actually your point #3 is interesting. I was talking to some guys a
while ago about using URIs (URN) or something instead of the confusing
class names, kinda like:
name: simple-appserver
location: localhost
services:
- type: brooklyn:.webapp:0.7.0:JBoss7Server
instead of:
- type: brooklyn.entity.webapp.jboss.JBoss7Server
... which would resolve to the appropriate class. That is introducing a
resolution mechanism.
Hadrian
On 07/14/2015 08:26 AM, Aled Sage wrote:
> Hi, thanks for that.
>
> I'd like us to treat this with caution for when we make the change. For
> example:
>
> 1. All open PRs will likely be affected (i.e. potentially needing
> significant rebasing).
> 2. Are our regression tests good enough, particularly with the impact
> on persisted state.
> Any improvements to do first?
> 3. What backwards compatibility guarantees do we want to give, e.g. of
> fully qualified names used in YAML blueprints.
>
> We should have a think about (2) and (3), to ensure we do the right prep
> before the rename.
>
> ---
> I hope that the refactor can be done relatively quickly in a modern IDE.
> (And searching the *.yaml files). Assuming that is true, then it may be
> worth doing a *dry run* and seeing what tests etc fail. Those could
> either be improved in the existing master (i.e. before the rename) so
> that they won't fail, or just note the required fixes so that we can do
> it quickly.
>
> We then may be able to plan ahead, to say that the rename will be done
> on a particular day. We could aim to merge other PRs before that, and
> everyone would know to expect major merge conflicts for anything we did
> that particular day.
>
> Does that seem feasible/sensible?!
>
> ---
> I also propose we change to 1.0.0-SNAPSHOT in preparation for all of the
> renames.
>
> I'll propose that again in a separate e-mail thread for discussion, as
> this one is already diverging from its original subject!
>
> Aled
>
>
>
> On 14/07/2015 12:59, Ciprian Ciubotariu wrote:
>> I can start working on the package rename on a fork of the master branch,
>> which can be rebased when integrating pending PRs. If we integrate
>> this branch
>> often back into master we can avoid blocking development.
>>
>>
>>
>> On Tuesday 14 July 2015 10:07:30 Aled Sage wrote:
>>> +1 for changing package name *after* the 0.7.0 release.
>>>
>>> I propose:
>>>
>>> * Release 0.7.0 with the existing package name
>>> (so that users have a stable (not milestone) release that they can
>>> use with confidence with minimal effort).
>>> * Work towards a 1.0:
>>> o clear any PR backlog
>>> o change the package names in master
>>> o document and thoroughly test the upgrade process from 0.7.0
>>> to 1.0
>>> (explicitly *not* support any other upgrade paths, such as
>>> 0.7.0-M2 to 1.0, etc)
>>> o see what other features / fixes the community demand/want in a
>>> 1.0 release.
>>>
>>> ---
>>> For version number, I also favour sticking with 0.7.0.
>>>
>>> Of the two options for that:
>>>
>>> 1. backport changes to the 0.7.x branch, or
>>> 2. delete + recreate that to incorporate all code that is currently in
>>> master, but reverting version number to 0.7.0...
>>>
>>> I prefer the backport option, if that's not too hard technically.
>>>
>>> Aled
>>>
>>> On 14/07/2015 09:13, Richard Downer wrote:
>>>> On the subject of changing the Java package name (which I forgot to
>>>> mention) - yes this is something that will need to be done and we have
>>>> discussed this previously. The decisions was that the in-development
>>>> version of 0.7.0 would *not* have this change, but that it would be
>>>> done
>>>> for 0.8.0.
>>>>
>>>> 0.7.0 has been brewing for a long time and I don't think there's the
>>>> appetite to do this right now. It's a major change, it would break our
>>>> user's code (which would be unfair on those that have been using
>>>> 0.7.0-M2)
>>>> and I've no doubt it would take weeks to fully shake out all the
>>>> bugs from
>>>> that kind of change. Meanwhile our users are clamouring for a 0.7.0
>>>> release as soon as we can :-)
>>>>
>>>> Once we've got 0.7.0 released then we'll kick off 0.8.0 development
>>>> proper
>>>> and have a discussion about what changes we want to include.
>>>>
>>>> Richard.
>>>>
>>>> On Tue, 14 Jul 2015 at 09:03 Richard Downer <ri...@apache.org> wrote:
>>>>> Hadrian, thanks very much for your efforts on this release blocker.
>>>>>
>>>>> I'm now back from vacation - I think that Sam is very busy this
>>>>> week so
>>>>> I'll put the Release Manager hat back on again and get an rc1 done
>>>>> today.
>>>>>
>>>>> Along with Svet I'm also in favour of option 1 - we have a release
>>>>> branch
>>>>> ready and we've already prepped some downstream customers to
>>>>> prepare for
>>>>> 0.7.0-final, so I'm not keen to change the version. I'm assuming that
>>>>> apart
>>>>> from the 0.7.0/0.8.0 difference, your changes should backport
>>>>> cleanly to
>>>>> the release branch.
>>>>>
>>>>> Should I be mistaken about the difficulty of this, then I will
>>>>> change my
>>>>> mind :-)
>>>>>
>>>>> Thanks again Hadrian and everyone else who has been looking at this
>>>>> problem.
>>>>>
>>>>> Richard.
>>>>>
>>>>>
>>>>> On Tue, 14 Jul 2015 at 08:58 Svetoslav Neykov <
>>>>>
>>>>> svetoslav.neykov@cloudsoftcorp.com> wrote:
>>>>>> I am for 1). As far as I know there's already a release branch
>>>>>> with some
>>>>>> backports. Another option is:
>>>>>>
>>>>>> 3. Create a 0.7.0 release off of the current master by changing
>>>>>> back the
>>>>>> version.
>>>>>>
>>>>>> Changing the package name should be done sooner rather than later,
>>>>>> but
>>>>>>
>>>>>> requires *very* careful planning due to:
>>>>>> * The need to keep backwards compatibility for existing
>>>>>> persistence
>>>>>>
>>>>>> stores. I'd prefer to have
>>>>>> https://github.com/apache/incubator-brooklyn/pull/738 <
>>>>>> https://github.com/apache/incubator-brooklyn/pull/738> merged before
>>>>>> attempting it.
>>>>>>
>>>>>> * Existing 3rd party blueprints better still be usable after the
>>>>>>
>>>>>> change, though this doesn't seem possible.
>>>>>>
>>>>>> Svet.
>>>>>>
>>>>>>> On 14.07.2015 г., at 5:40, Hadrian Zbarcea <hz...@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> My proposed changes to unblock the release are now complete [1].
>>>>>>> They
>>>>>> are done however on the master, which leaves us with one of the
>>>>>> following
>>>>>> options (if I am not missing something)
>>>>>>
>>>>>>> 1. Backport to a 0.7.0-Mxxx branch
>>>>>>> 2. Abandon 0.7.0-Mxxx and release at 0.8.0
>>>>>>>
>>>>>>> While either work, I somewhat prefer moving on with #2 as the
>>>>>>> simplest
>>>>>> solution.
>>>>>>
>>>>>>> Another thought is that migrating packages from brooklyn.* to
>>>>>> org.apache.brooklyn.* will be necessary at some point. I suspect best
>>>>>> would
>>>>>> be to do it now before a release.
>>>>>>
>>>>>>> Thoughts?
>>>>>>> Hadrian
>>>>>>>
>>>>>>> [1] https://github.com/apache/incubator-brooklyn/pull/737
>>>>>>>
>>>>>>> On 06/27/2015 09:09 PM, Hadrian Zbarcea wrote:
>>>>>>>> This is not an easy one and imho would require some community
>>>>>>>> choice
>>>>>>>> before implementing a solution.
>>>>>>>>
>>>>>>>> 1. To be able to release downstream-parent, it would have to
>>>>>>>> have the
>>>>>>>> proper configuration, specifically for the release and gpg maven
>>>>>>>> plugins, that comes actually from the org.apache:apache:17 parent.
>>>>>>>> 2. Consequently, the downstream parent should have either
>>>>>>>> org.apache:apache:17 or even better
>>>>>>>> org.apache.brooklyn:brooklyn-parent
>>>>>>>> as a parent.
>>>>>>>> 3. The downstream-parent is only used in the quickstart archetype.
>>>>>>>>
>>>>>>>> There is questionable value in having a downstream-parent that
>>>>>>>> users
>>>>>>>> would have to change anyway if it caries the apache scp and release
>>>>>>>> configurations that wouldn't apply for a user's project.
>>>>>>>>
>>>>>>>> The only 2 solutions I can think of are to:
>>>>>>>> a. Get rid of the downstream parent and move all the necessary
>>>>>>>> incantations in the quickstart archetype.
>>>>>>>> b. Transform the downstream-parent (and maybe come up with a better
>>>>>> name
>>>>>>
>>>>>>>> for it) into a <scope>import</scope> pom [1].
>>>>>>>>
>>>>>>>> I think this is a blocker for the release.
>>>>>>>>
>>>>>>>> Thoughts?
>>>>>>>> Hadrian
>>>>>>>>
>>>>>>>> [1]
>>>>>> https://maven.apache.org/guides/introduction/introduction-to-dependency->
>>>>>> >>> mechanism.html#Importing_Dependencies>>>
>>>>>>>> On 06/27/2015 04:05 AM, Andrea Turli wrote:
>>>>>>>>> Thanks Hadrian,
>>>>>>>>>
>>>>>>>>> I've also found this one while googling for another project
>>>>>>>>> [1], so
>>>>>>>>> either
>>>>>>>>> Apache parent or nothing should fix the issue.
>>>>>>>>>
>>>>>>>>> HTH,
>>>>>>>>> Andrea
>>>>>>>>> [1]:
>>>>>> http://central.sonatype.org/pages/apache-maven.html#deprecated-oss-paren
>>>>>>
>>>>>> t
>>>>>>
>>>>>>>>> On Sat, 27 Jun 2015 at 05:58 Hadrian Zbarcea <hz...@gmail.com>
>>>>>> wrote:
>>>>>>>>>> First thing, the <parent> for the brooklyn-downstream-parent
>>>>>>>>>> should
>>>>>>>>>>
>>>>>>>>>> not be:
>>>>>>>>>> <parent>
>>>>>>>>>> <groupId>org.sonatype.oss</groupId>
>>>>>>>>>> <artifactId>oss-parent</artifactId>
>>>>>>>>>> <version>9</version>
>>>>>>>>>> </parent>
>>>>>>>>>>
>>>>>>>>>> but the apache parent ultimately. I think this should completely
>>>>>> resolve
>>>>>>
>>>>>>>>>> the problem. It's a bit late here to test, I'll do it tomorrow.
>>>>>>>>>>
>>>>>>>>>> Cheers,
>>>>>>>>>> Hadrian
>>>>>>>>>>
>>>>>>>>>> On 06/26/2015 11:35 PM, Hadrian Zbarcea wrote:
>>>>>>>>>>> I did try a dryRun myself and did encounter a problem with the
>>>>>>>>>>> brooklyn-downstream-parent, but of a different nature
>>>>>>>>>>> "'parent.relativePath' points at wrong local POM", but I suspect
>>>>>> there
>>>>>>
>>>>>>>>>>> more issues there. From my experience releasing other
>>>>>>>>>>> projects, I
>>>>>>>>>>> try to
>>>>>>>>>>> first remove relevant branches from my local maven repo before
>>>>>>>>>>> preparing
>>>>>>>>>>> a release.
>>>>>>>>>>>
>>>>>>>>>>> I will look at it during the weekend. Somebody should revert the
>>>>>>>>>>> version
>>>>>>>>>>> back from 0.8.0-SNAPSHOT though.
>>>>>>>>>>>
>>>>>>>>>>> Cheers,
>>>>>>>>>>> Hadrian
>>>>>>>>>>>
>>>>>>>>>>> On 06/26/2015 04:53 PM, Richard Downer wrote:
>>>>>>>>>>>> So we got all the source code lined up today, and the release
>>>>>> branch
>>>>>>
>>>>>>>>>>>> made.
>>>>>>>>>>>> Everything was going very promisingly until I tried to close
>>>>>>>>>>>> the
>>>>>> Nexus
>>>>>>
>>>>>>>>>>>> repository to publish the artifacts and got a rule violation
>>>>>>>>>>>> error.
>>>>>>>>>>>>
>>>>>>>>>>>> I'll have a look at fixing the problem and re-starting the
>>>>>>>>>>>> release
>>>>>> on
>>>>>>
>>>>>>>>>>>> Monday (unfortunately I won't have any availability to look at
>>>>>>>>>>>> this
>>>>>>>>>>>> over
>>>>>>>>>>>> the weekend).
>>>>>>>>>>>>
>>>>>>>>>>>> In the meantime if anyone is looking for something to do
>>>>>>>>>>>> over the
>>>>>>>>>>>> weekend,
>>>>>>>>>>>> the exact failure Nexus reported was:
>>>>>>>>>>>> Missing Signature:
>>>>>> '/org/apache/brooklyn/brooklyn-downstream-parent/0.7.0-incubating/brookl
>>>>>>
>>>>>> yn-downstream-parent-0.7.0-incubating.pom.asc'>>>
>>>>>>>>>>>> does not exist for
>>>>>> 'brooklyn-downstream-parent-0.7.0-incubating.pom'.
>>>>>>
>>>>>>>>>>>> Everything else has a .pom.asc except downstream-parent so it
>>>>>>>>>>>> seems
>>>>>>>>>>>> there's
>>>>>>>>>>>> something special about this project.
>>>>>>>>>>>>
>>>>>>>>>>>> Richard.
>>>>>> --
>>>>>> Cloudsoft Corporation Limited, Registered in Scotland No: SC349230.
>>>>>>
>>>>>> Registered Office: 13 Dryden Place, Edinburgh, EH9 1RP
>>>>>>
>>>>>> This e-mail message is confidential and for use by the addressee
>>>>>> only.
>>>>>> If
>>>>>> the message is received by anyone other than the addressee, please
>>>>>> return
>>>>>> the message to the sender by replying to it and then delete the
>>>>>> message
>>>>>> from your computer. Internet e-mails are not necessarily secure.
>>>>>> Cloudsoft
>>>>>> Corporation Limited does not accept responsibility for changes
>>>>>> made to
>>>>>> this
>>>>>> message after it was sent.
>>>>>>
>>>>>> Whilst all reasonable care has been taken to avoid the
>>>>>> transmission of
>>>>>> viruses, it is the responsibility of the recipient to ensure that the
>>>>>> onward transmission, opening or use of this message and any
>>>>>> attachments
>>>>>> will not adversely affect its systems or data. No responsibility is
>>>>>> accepted by Cloudsoft Corporation Limited in this regard and the
>>>>>> recipient
>>>>>> should carry out such virus and other checks as it considers
>>>>>> appropriate.
>
>
Re: No 0.7.0-rc1 release today :(
Posted by Aled Sage <al...@gmail.com>.
Hi, thanks for that.
I'd like us to treat this with caution for when we make the change. For
example:
1. All open PRs will likely be affected (i.e. potentially needing
significant rebasing).
2. Are our regression tests good enough, particularly with the impact
on persisted state.
Any improvements to do first?
3. What backwards compatibility guarantees do we want to give, e.g. of
fully qualified names used in YAML blueprints.
We should have a think about (2) and (3), to ensure we do the right prep
before the rename.
---
I hope that the refactor can be done relatively quickly in a modern IDE.
(And searching the *.yaml files). Assuming that is true, then it may be
worth doing a *dry run* and seeing what tests etc fail. Those could
either be improved in the existing master (i.e. before the rename) so
that they won't fail, or just note the required fixes so that we can do
it quickly.
We then may be able to plan ahead, to say that the rename will be done
on a particular day. We could aim to merge other PRs before that, and
everyone would know to expect major merge conflicts for anything we did
that particular day.
Does that seem feasible/sensible?!
---
I also propose we change to 1.0.0-SNAPSHOT in preparation for all of the
renames.
I'll propose that again in a separate e-mail thread for discussion, as
this one is already diverging from its original subject!
Aled
On 14/07/2015 12:59, Ciprian Ciubotariu wrote:
> I can start working on the package rename on a fork of the master branch,
> which can be rebased when integrating pending PRs. If we integrate this branch
> often back into master we can avoid blocking development.
>
>
>
> On Tuesday 14 July 2015 10:07:30 Aled Sage wrote:
>> +1 for changing package name *after* the 0.7.0 release.
>>
>> I propose:
>>
>> * Release 0.7.0 with the existing package name
>> (so that users have a stable (not milestone) release that they can
>> use with confidence with minimal effort).
>> * Work towards a 1.0:
>> o clear any PR backlog
>> o change the package names in master
>> o document and thoroughly test the upgrade process from 0.7.0 to 1.0
>> (explicitly *not* support any other upgrade paths, such as
>> 0.7.0-M2 to 1.0, etc)
>> o see what other features / fixes the community demand/want in a
>> 1.0 release.
>>
>> ---
>> For version number, I also favour sticking with 0.7.0.
>>
>> Of the two options for that:
>>
>> 1. backport changes to the 0.7.x branch, or
>> 2. delete + recreate that to incorporate all code that is currently in
>> master, but reverting version number to 0.7.0...
>>
>> I prefer the backport option, if that's not too hard technically.
>>
>> Aled
>>
>> On 14/07/2015 09:13, Richard Downer wrote:
>>> On the subject of changing the Java package name (which I forgot to
>>> mention) - yes this is something that will need to be done and we have
>>> discussed this previously. The decisions was that the in-development
>>> version of 0.7.0 would *not* have this change, but that it would be done
>>> for 0.8.0.
>>>
>>> 0.7.0 has been brewing for a long time and I don't think there's the
>>> appetite to do this right now. It's a major change, it would break our
>>> user's code (which would be unfair on those that have been using 0.7.0-M2)
>>> and I've no doubt it would take weeks to fully shake out all the bugs from
>>> that kind of change. Meanwhile our users are clamouring for a 0.7.0
>>> release as soon as we can :-)
>>>
>>> Once we've got 0.7.0 released then we'll kick off 0.8.0 development proper
>>> and have a discussion about what changes we want to include.
>>>
>>> Richard.
>>>
>>> On Tue, 14 Jul 2015 at 09:03 Richard Downer <ri...@apache.org> wrote:
>>>> Hadrian, thanks very much for your efforts on this release blocker.
>>>>
>>>> I'm now back from vacation - I think that Sam is very busy this week so
>>>> I'll put the Release Manager hat back on again and get an rc1 done today.
>>>>
>>>> Along with Svet I'm also in favour of option 1 - we have a release branch
>>>> ready and we've already prepped some downstream customers to prepare for
>>>> 0.7.0-final, so I'm not keen to change the version. I'm assuming that
>>>> apart
>>>> from the 0.7.0/0.8.0 difference, your changes should backport cleanly to
>>>> the release branch.
>>>>
>>>> Should I be mistaken about the difficulty of this, then I will change my
>>>> mind :-)
>>>>
>>>> Thanks again Hadrian and everyone else who has been looking at this
>>>> problem.
>>>>
>>>> Richard.
>>>>
>>>>
>>>> On Tue, 14 Jul 2015 at 08:58 Svetoslav Neykov <
>>>>
>>>> svetoslav.neykov@cloudsoftcorp.com> wrote:
>>>>> I am for 1). As far as I know there's already a release branch with some
>>>>> backports. Another option is:
>>>>>
>>>>> 3. Create a 0.7.0 release off of the current master by changing back the
>>>>> version.
>>>>>
>>>>> Changing the package name should be done sooner rather than later, but
>>>>>
>>>>> requires *very* careful planning due to:
>>>>> * The need to keep backwards compatibility for existing persistence
>>>>>
>>>>> stores. I'd prefer to have
>>>>> https://github.com/apache/incubator-brooklyn/pull/738 <
>>>>> https://github.com/apache/incubator-brooklyn/pull/738> merged before
>>>>> attempting it.
>>>>>
>>>>> * Existing 3rd party blueprints better still be usable after the
>>>>>
>>>>> change, though this doesn't seem possible.
>>>>>
>>>>> Svet.
>>>>>
>>>>>> On 14.07.2015 г., at 5:40, Hadrian Zbarcea <hz...@gmail.com> wrote:
>>>>>>
>>>>>> My proposed changes to unblock the release are now complete [1]. They
>>>>> are done however on the master, which leaves us with one of the
>>>>> following
>>>>> options (if I am not missing something)
>>>>>
>>>>>> 1. Backport to a 0.7.0-Mxxx branch
>>>>>> 2. Abandon 0.7.0-Mxxx and release at 0.8.0
>>>>>>
>>>>>> While either work, I somewhat prefer moving on with #2 as the simplest
>>>>> solution.
>>>>>
>>>>>> Another thought is that migrating packages from brooklyn.* to
>>>>> org.apache.brooklyn.* will be necessary at some point. I suspect best
>>>>> would
>>>>> be to do it now before a release.
>>>>>
>>>>>> Thoughts?
>>>>>> Hadrian
>>>>>>
>>>>>> [1] https://github.com/apache/incubator-brooklyn/pull/737
>>>>>>
>>>>>> On 06/27/2015 09:09 PM, Hadrian Zbarcea wrote:
>>>>>>> This is not an easy one and imho would require some community choice
>>>>>>> before implementing a solution.
>>>>>>>
>>>>>>> 1. To be able to release downstream-parent, it would have to have the
>>>>>>> proper configuration, specifically for the release and gpg maven
>>>>>>> plugins, that comes actually from the org.apache:apache:17 parent.
>>>>>>> 2. Consequently, the downstream parent should have either
>>>>>>> org.apache:apache:17 or even better
>>>>>>> org.apache.brooklyn:brooklyn-parent
>>>>>>> as a parent.
>>>>>>> 3. The downstream-parent is only used in the quickstart archetype.
>>>>>>>
>>>>>>> There is questionable value in having a downstream-parent that users
>>>>>>> would have to change anyway if it caries the apache scp and release
>>>>>>> configurations that wouldn't apply for a user's project.
>>>>>>>
>>>>>>> The only 2 solutions I can think of are to:
>>>>>>> a. Get rid of the downstream parent and move all the necessary
>>>>>>> incantations in the quickstart archetype.
>>>>>>> b. Transform the downstream-parent (and maybe come up with a better
>>>>> name
>>>>>
>>>>>>> for it) into a <scope>import</scope> pom [1].
>>>>>>>
>>>>>>> I think this is a blocker for the release.
>>>>>>>
>>>>>>> Thoughts?
>>>>>>> Hadrian
>>>>>>>
>>>>>>> [1]
>>>>> https://maven.apache.org/guides/introduction/introduction-to-dependency-> >>> mechanism.html#Importing_Dependencies>>>
>>>>>>> On 06/27/2015 04:05 AM, Andrea Turli wrote:
>>>>>>>> Thanks Hadrian,
>>>>>>>>
>>>>>>>> I've also found this one while googling for another project [1], so
>>>>>>>> either
>>>>>>>> Apache parent or nothing should fix the issue.
>>>>>>>>
>>>>>>>> HTH,
>>>>>>>> Andrea
>>>>>>>> [1]:
>>>>> http://central.sonatype.org/pages/apache-maven.html#deprecated-oss-paren
>>>>> t
>>>>>
>>>>>>>> On Sat, 27 Jun 2015 at 05:58 Hadrian Zbarcea <hz...@gmail.com>
>>>>> wrote:
>>>>>>>>> First thing, the <parent> for the brooklyn-downstream-parent should
>>>>>>>>>
>>>>>>>>> not be:
>>>>>>>>> <parent>
>>>>>>>>>
>>>>>>>>> <groupId>org.sonatype.oss</groupId>
>>>>>>>>> <artifactId>oss-parent</artifactId>
>>>>>>>>> <version>9</version>
>>>>>>>>>
>>>>>>>>> </parent>
>>>>>>>>>
>>>>>>>>> but the apache parent ultimately. I think this should completely
>>>>> resolve
>>>>>
>>>>>>>>> the problem. It's a bit late here to test, I'll do it tomorrow.
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> Hadrian
>>>>>>>>>
>>>>>>>>> On 06/26/2015 11:35 PM, Hadrian Zbarcea wrote:
>>>>>>>>>> I did try a dryRun myself and did encounter a problem with the
>>>>>>>>>> brooklyn-downstream-parent, but of a different nature
>>>>>>>>>> "'parent.relativePath' points at wrong local POM", but I suspect
>>>>> there
>>>>>
>>>>>>>>>> more issues there. From my experience releasing other projects, I
>>>>>>>>>> try to
>>>>>>>>>> first remove relevant branches from my local maven repo before
>>>>>>>>>> preparing
>>>>>>>>>> a release.
>>>>>>>>>>
>>>>>>>>>> I will look at it during the weekend. Somebody should revert the
>>>>>>>>>> version
>>>>>>>>>> back from 0.8.0-SNAPSHOT though.
>>>>>>>>>>
>>>>>>>>>> Cheers,
>>>>>>>>>> Hadrian
>>>>>>>>>>
>>>>>>>>>> On 06/26/2015 04:53 PM, Richard Downer wrote:
>>>>>>>>>>> So we got all the source code lined up today, and the release
>>>>> branch
>>>>>
>>>>>>>>>>> made.
>>>>>>>>>>> Everything was going very promisingly until I tried to close the
>>>>> Nexus
>>>>>
>>>>>>>>>>> repository to publish the artifacts and got a rule violation
>>>>>>>>>>> error.
>>>>>>>>>>>
>>>>>>>>>>> I'll have a look at fixing the problem and re-starting the release
>>>>> on
>>>>>
>>>>>>>>>>> Monday (unfortunately I won't have any availability to look at
>>>>>>>>>>> this
>>>>>>>>>>> over
>>>>>>>>>>> the weekend).
>>>>>>>>>>>
>>>>>>>>>>> In the meantime if anyone is looking for something to do over the
>>>>>>>>>>> weekend,
>>>>>>>>>>> the exact failure Nexus reported was:
>>>>>>>>>>> Missing Signature:
>>>>> '/org/apache/brooklyn/brooklyn-downstream-parent/0.7.0-incubating/brookl
>>>>> yn-downstream-parent-0.7.0-incubating.pom.asc'>>>
>>>>>>>>>>> does not exist for
>>>>> 'brooklyn-downstream-parent-0.7.0-incubating.pom'.
>>>>>
>>>>>>>>>>> Everything else has a .pom.asc except downstream-parent so it
>>>>>>>>>>> seems
>>>>>>>>>>> there's
>>>>>>>>>>> something special about this project.
>>>>>>>>>>>
>>>>>>>>>>> Richard.
>>>>> --
>>>>> Cloudsoft Corporation Limited, Registered in Scotland No: SC349230.
>>>>>
>>>>> Registered Office: 13 Dryden Place, Edinburgh, EH9 1RP
>>>>>
>>>>> This e-mail message is confidential and for use by the addressee only.
>>>>> If
>>>>> the message is received by anyone other than the addressee, please
>>>>> return
>>>>> the message to the sender by replying to it and then delete the message
>>>>> from your computer. Internet e-mails are not necessarily secure.
>>>>> Cloudsoft
>>>>> Corporation Limited does not accept responsibility for changes made to
>>>>> this
>>>>> message after it was sent.
>>>>>
>>>>> Whilst all reasonable care has been taken to avoid the transmission of
>>>>> viruses, it is the responsibility of the recipient to ensure that the
>>>>> onward transmission, opening or use of this message and any attachments
>>>>> will not adversely affect its systems or data. No responsibility is
>>>>> accepted by Cloudsoft Corporation Limited in this regard and the
>>>>> recipient
>>>>> should carry out such virus and other checks as it considers
>>>>> appropriate.
Re: No 0.7.0-rc1 release today :(
Posted by Ciprian Ciubotariu <ch...@gmx.net>.
I can start working on the package rename on a fork of the master branch,
which can be rebased when integrating pending PRs. If we integrate this branch
often back into master we can avoid blocking development.
On Tuesday 14 July 2015 10:07:30 Aled Sage wrote:
> +1 for changing package name *after* the 0.7.0 release.
>
> I propose:
>
> * Release 0.7.0 with the existing package name
> (so that users have a stable (not milestone) release that they can
> use with confidence with minimal effort).
> * Work towards a 1.0:
> o clear any PR backlog
> o change the package names in master
> o document and thoroughly test the upgrade process from 0.7.0 to 1.0
> (explicitly *not* support any other upgrade paths, such as
> 0.7.0-M2 to 1.0, etc)
> o see what other features / fixes the community demand/want in a
> 1.0 release.
>
> ---
> For version number, I also favour sticking with 0.7.0.
>
> Of the two options for that:
>
> 1. backport changes to the 0.7.x branch, or
> 2. delete + recreate that to incorporate all code that is currently in
> master, but reverting version number to 0.7.0...
>
> I prefer the backport option, if that's not too hard technically.
>
> Aled
>
> On 14/07/2015 09:13, Richard Downer wrote:
> > On the subject of changing the Java package name (which I forgot to
> > mention) - yes this is something that will need to be done and we have
> > discussed this previously. The decisions was that the in-development
> > version of 0.7.0 would *not* have this change, but that it would be done
> > for 0.8.0.
> >
> > 0.7.0 has been brewing for a long time and I don't think there's the
> > appetite to do this right now. It's a major change, it would break our
> > user's code (which would be unfair on those that have been using 0.7.0-M2)
> > and I've no doubt it would take weeks to fully shake out all the bugs from
> > that kind of change. Meanwhile our users are clamouring for a 0.7.0
> > release as soon as we can :-)
> >
> > Once we've got 0.7.0 released then we'll kick off 0.8.0 development proper
> > and have a discussion about what changes we want to include.
> >
> > Richard.
> >
> > On Tue, 14 Jul 2015 at 09:03 Richard Downer <ri...@apache.org> wrote:
> >> Hadrian, thanks very much for your efforts on this release blocker.
> >>
> >> I'm now back from vacation - I think that Sam is very busy this week so
> >> I'll put the Release Manager hat back on again and get an rc1 done today.
> >>
> >> Along with Svet I'm also in favour of option 1 - we have a release branch
> >> ready and we've already prepped some downstream customers to prepare for
> >> 0.7.0-final, so I'm not keen to change the version. I'm assuming that
> >> apart
> >> from the 0.7.0/0.8.0 difference, your changes should backport cleanly to
> >> the release branch.
> >>
> >> Should I be mistaken about the difficulty of this, then I will change my
> >> mind :-)
> >>
> >> Thanks again Hadrian and everyone else who has been looking at this
> >> problem.
> >>
> >> Richard.
> >>
> >>
> >> On Tue, 14 Jul 2015 at 08:58 Svetoslav Neykov <
> >>
> >> svetoslav.neykov@cloudsoftcorp.com> wrote:
> >>> I am for 1). As far as I know there's already a release branch with some
> >>> backports. Another option is:
> >>>
> >>> 3. Create a 0.7.0 release off of the current master by changing back the
> >>> version.
> >>>
> >>> Changing the package name should be done sooner rather than later, but
> >>>
> >>> requires *very* careful planning due to:
> >>> * The need to keep backwards compatibility for existing persistence
> >>>
> >>> stores. I'd prefer to have
> >>> https://github.com/apache/incubator-brooklyn/pull/738 <
> >>> https://github.com/apache/incubator-brooklyn/pull/738> merged before
> >>> attempting it.
> >>>
> >>> * Existing 3rd party blueprints better still be usable after the
> >>>
> >>> change, though this doesn't seem possible.
> >>>
> >>> Svet.
> >>>
> >>>> On 14.07.2015 г., at 5:40, Hadrian Zbarcea <hz...@gmail.com> wrote:
> >>>>
> >>>> My proposed changes to unblock the release are now complete [1]. They
> >>>
> >>> are done however on the master, which leaves us with one of the
> >>> following
> >>> options (if I am not missing something)
> >>>
> >>>> 1. Backport to a 0.7.0-Mxxx branch
> >>>> 2. Abandon 0.7.0-Mxxx and release at 0.8.0
> >>>>
> >>>> While either work, I somewhat prefer moving on with #2 as the simplest
> >>>
> >>> solution.
> >>>
> >>>> Another thought is that migrating packages from brooklyn.* to
> >>>
> >>> org.apache.brooklyn.* will be necessary at some point. I suspect best
> >>> would
> >>> be to do it now before a release.
> >>>
> >>>> Thoughts?
> >>>> Hadrian
> >>>>
> >>>> [1] https://github.com/apache/incubator-brooklyn/pull/737
> >>>>
> >>>> On 06/27/2015 09:09 PM, Hadrian Zbarcea wrote:
> >>>>> This is not an easy one and imho would require some community choice
> >>>>> before implementing a solution.
> >>>>>
> >>>>> 1. To be able to release downstream-parent, it would have to have the
> >>>>> proper configuration, specifically for the release and gpg maven
> >>>>> plugins, that comes actually from the org.apache:apache:17 parent.
> >>>>> 2. Consequently, the downstream parent should have either
> >>>>> org.apache:apache:17 or even better
> >>>>> org.apache.brooklyn:brooklyn-parent
> >>>>> as a parent.
> >>>>> 3. The downstream-parent is only used in the quickstart archetype.
> >>>>>
> >>>>> There is questionable value in having a downstream-parent that users
> >>>>> would have to change anyway if it caries the apache scp and release
> >>>>> configurations that wouldn't apply for a user's project.
> >>>>>
> >>>>> The only 2 solutions I can think of are to:
> >>>>> a. Get rid of the downstream parent and move all the necessary
> >>>>> incantations in the quickstart archetype.
> >>>>> b. Transform the downstream-parent (and maybe come up with a better
> >>>
> >>> name
> >>>
> >>>>> for it) into a <scope>import</scope> pom [1].
> >>>>>
> >>>>> I think this is a blocker for the release.
> >>>>>
> >>>>> Thoughts?
> >>>>> Hadrian
> >>>>>
> >>>>> [1]
> >>>
> >>> https://maven.apache.org/guides/introduction/introduction-to-dependency-> >>> mechanism.html#Importing_Dependencies>>>
> >>>>> On 06/27/2015 04:05 AM, Andrea Turli wrote:
> >>>>>> Thanks Hadrian,
> >>>>>>
> >>>>>> I've also found this one while googling for another project [1], so
> >>>>>> either
> >>>>>> Apache parent or nothing should fix the issue.
> >>>>>>
> >>>>>> HTH,
> >>>>>> Andrea
> >>>
> >>>>>> [1]:
> >>> http://central.sonatype.org/pages/apache-maven.html#deprecated-oss-paren
> >>> t
> >>>
> >>>>>> On Sat, 27 Jun 2015 at 05:58 Hadrian Zbarcea <hz...@gmail.com>
> >>>
> >>> wrote:
> >>>>>>> First thing, the <parent> for the brooklyn-downstream-parent should
> >>>>>>>
> >>>>>>> not be:
> >>>>>>> <parent>
> >>>>>>>
> >>>>>>> <groupId>org.sonatype.oss</groupId>
> >>>>>>> <artifactId>oss-parent</artifactId>
> >>>>>>> <version>9</version>
> >>>>>>>
> >>>>>>> </parent>
> >>>>>>>
> >>>>>>> but the apache parent ultimately. I think this should completely
> >>>
> >>> resolve
> >>>
> >>>>>>> the problem. It's a bit late here to test, I'll do it tomorrow.
> >>>>>>>
> >>>>>>> Cheers,
> >>>>>>> Hadrian
> >>>>>>>
> >>>>>>> On 06/26/2015 11:35 PM, Hadrian Zbarcea wrote:
> >>>>>>>> I did try a dryRun myself and did encounter a problem with the
> >>>>>>>> brooklyn-downstream-parent, but of a different nature
> >>>>>>>> "'parent.relativePath' points at wrong local POM", but I suspect
> >>>
> >>> there
> >>>
> >>>>>>>> more issues there. From my experience releasing other projects, I
> >>>>>>>> try to
> >>>>>>>> first remove relevant branches from my local maven repo before
> >>>>>>>> preparing
> >>>>>>>> a release.
> >>>>>>>>
> >>>>>>>> I will look at it during the weekend. Somebody should revert the
> >>>>>>>> version
> >>>>>>>> back from 0.8.0-SNAPSHOT though.
> >>>>>>>>
> >>>>>>>> Cheers,
> >>>>>>>> Hadrian
> >>>>>>>>
> >>>>>>>> On 06/26/2015 04:53 PM, Richard Downer wrote:
> >>>>>>>>> So we got all the source code lined up today, and the release
> >>>
> >>> branch
> >>>
> >>>>>>>>> made.
> >>>>>>>>> Everything was going very promisingly until I tried to close the
> >>>
> >>> Nexus
> >>>
> >>>>>>>>> repository to publish the artifacts and got a rule violation
> >>>>>>>>> error.
> >>>>>>>>>
> >>>>>>>>> I'll have a look at fixing the problem and re-starting the release
> >>>
> >>> on
> >>>
> >>>>>>>>> Monday (unfortunately I won't have any availability to look at
> >>>>>>>>> this
> >>>>>>>>> over
> >>>>>>>>> the weekend).
> >>>>>>>>>
> >>>>>>>>> In the meantime if anyone is looking for something to do over the
> >>>>>>>>> weekend,
> >>>>>>>>> the exact failure Nexus reported was:
> >>>
> >>>>>>>>> Missing Signature:
> >>> '/org/apache/brooklyn/brooklyn-downstream-parent/0.7.0-incubating/brookl
> >>> yn-downstream-parent-0.7.0-incubating.pom.asc'>>>
> >>>>>>>>> does not exist for
> >>>
> >>> 'brooklyn-downstream-parent-0.7.0-incubating.pom'.
> >>>
> >>>>>>>>> Everything else has a .pom.asc except downstream-parent so it
> >>>>>>>>> seems
> >>>>>>>>> there's
> >>>>>>>>> something special about this project.
> >>>>>>>>>
> >>>>>>>>> Richard.
> >>>
> >>> --
> >>> Cloudsoft Corporation Limited, Registered in Scotland No: SC349230.
> >>>
> >>> Registered Office: 13 Dryden Place, Edinburgh, EH9 1RP
> >>>
> >>> This e-mail message is confidential and for use by the addressee only.
> >>> If
> >>> the message is received by anyone other than the addressee, please
> >>> return
> >>> the message to the sender by replying to it and then delete the message
> >>> from your computer. Internet e-mails are not necessarily secure.
> >>> Cloudsoft
> >>> Corporation Limited does not accept responsibility for changes made to
> >>> this
> >>> message after it was sent.
> >>>
> >>> Whilst all reasonable care has been taken to avoid the transmission of
> >>> viruses, it is the responsibility of the recipient to ensure that the
> >>> onward transmission, opening or use of this message and any attachments
> >>> will not adversely affect its systems or data. No responsibility is
> >>> accepted by Cloudsoft Corporation Limited in this regard and the
> >>> recipient
> >>> should carry out such virus and other checks as it considers
> >>> appropriate.
Re: No 0.7.0-rc1 release today :(
Posted by Richard Downer <ri...@apache.org>.
Thanks Hadrian, but no need, I've backported it to the release branch.
Consider this to be the code review before I merge the PR :-) (All seems to
be working well so far, BTW.)
Richard.
On Tue, 14 Jul 2015 at 11:30 Hadrian Zbarcea <hz...@gmail.com> wrote:
> It should be a trivial port, nothing specific to 0.8.0. Once the PR is
> merged I can create another PR.
>
> Cheers,
> Hadrian
>
> On 07/14/2015 05:07 AM, Aled Sage wrote:
> > +1 for changing package name *after* the 0.7.0 release.
> >
> > I propose:
> >
> > * Release 0.7.0 with the existing package name
> > (so that users have a stable (not milestone) release that they can
> > use with confidence with minimal effort).
> > * Work towards a 1.0:
> > o clear any PR backlog
> > o change the package names in master
> > o document and thoroughly test the upgrade process from 0.7.0 to
> 1.0
> > (explicitly *not* support any other upgrade paths, such as
> > 0.7.0-M2 to 1.0, etc)
> > o see what other features / fixes the community demand/want in a
> > 1.0 release.
> >
> > ---
> > For version number, I also favour sticking with 0.7.0.
> >
> > Of the two options for that:
> >
> > 1. backport changes to the 0.7.x branch, or
> > 2. delete + recreate that to incorporate all code that is currently in
> > master, but reverting version number to 0.7.0...
> >
> > I prefer the backport option, if that's not too hard technically.
> >
> > Aled
> >
> >
> > On 14/07/2015 09:13, Richard Downer wrote:
> >> On the subject of changing the Java package name (which I forgot to
> >> mention) - yes this is something that will need to be done and we have
> >> discussed this previously. The decisions was that the in-development
> >> version of 0.7.0 would *not* have this change, but that it would be done
> >> for 0.8.0.
> >>
> >> 0.7.0 has been brewing for a long time and I don't think there's the
> >> appetite to do this right now. It's a major change, it would break our
> >> user's code (which would be unfair on those that have been using
> >> 0.7.0-M2)
> >> and I've no doubt it would take weeks to fully shake out all the bugs
> >> from
> >> that kind of change. Meanwhile our users are clamouring for a 0.7.0
> >> release as soon as we can :-)
> >>
> >> Once we've got 0.7.0 released then we'll kick off 0.8.0 development
> >> proper
> >> and have a discussion about what changes we want to include.
> >>
> >> Richard.
> >>
> >>
> >> On Tue, 14 Jul 2015 at 09:03 Richard Downer <ri...@apache.org> wrote:
> >>
> >>> Hadrian, thanks very much for your efforts on this release blocker.
> >>>
> >>> I'm now back from vacation - I think that Sam is very busy this week so
> >>> I'll put the Release Manager hat back on again and get an rc1 done
> >>> today.
> >>>
> >>> Along with Svet I'm also in favour of option 1 - we have a release
> >>> branch
> >>> ready and we've already prepped some downstream customers to prepare
> for
> >>> 0.7.0-final, so I'm not keen to change the version. I'm assuming that
> >>> apart
> >>> from the 0.7.0/0.8.0 difference, your changes should backport cleanly
> to
> >>> the release branch.
> >>>
> >>> Should I be mistaken about the difficulty of this, then I will change
> my
> >>> mind :-)
> >>>
> >>> Thanks again Hadrian and everyone else who has been looking at this
> >>> problem.
> >>>
> >>> Richard.
> >>>
> >>>
> >>> On Tue, 14 Jul 2015 at 08:58 Svetoslav Neykov <
> >>> svetoslav.neykov@cloudsoftcorp.com> wrote:
> >>>
> >>>> I am for 1). As far as I know there's already a release branch with
> >>>> some
> >>>> backports. Another option is:
> >>>>
> >>>> 3. Create a 0.7.0 release off of the current master by changing back
> >>>> the
> >>>> version.
> >>>>
> >>>> Changing the package name should be done sooner rather than later, but
> >>>> requires *very* careful planning due to:
> >>>> * The need to keep backwards compatibility for existing persistence
> >>>> stores. I'd prefer to have
> >>>> https://github.com/apache/incubator-brooklyn/pull/738 <
> >>>> https://github.com/apache/incubator-brooklyn/pull/738> merged before
> >>>> attempting it.
> >>>> * Existing 3rd party blueprints better still be usable after the
> >>>> change, though this doesn't seem possible.
> >>>>
> >>>> Svet.
> >>>>
> >>>>
> >>>>> On 14.07.2015 г., at 5:40, Hadrian Zbarcea <hz...@gmail.com>
> wrote:
> >>>>>
> >>>>> My proposed changes to unblock the release are now complete [1]. They
> >>>> are done however on the master, which leaves us with one of the
> >>>> following
> >>>> options (if I am not missing something)
> >>>>> 1. Backport to a 0.7.0-Mxxx branch
> >>>>> 2. Abandon 0.7.0-Mxxx and release at 0.8.0
> >>>>>
> >>>>> While either work, I somewhat prefer moving on with #2 as the
> simplest
> >>>> solution.
> >>>>> Another thought is that migrating packages from brooklyn.* to
> >>>> org.apache.brooklyn.* will be necessary at some point. I suspect
> >>>> best would
> >>>> be to do it now before a release.
> >>>>> Thoughts?
> >>>>> Hadrian
> >>>>>
> >>>>> [1] https://github.com/apache/incubator-brooklyn/pull/737
> >>>>>
> >>>>>
> >>>>> On 06/27/2015 09:09 PM, Hadrian Zbarcea wrote:
> >>>>>> This is not an easy one and imho would require some community choice
> >>>>>> before implementing a solution.
> >>>>>>
> >>>>>> 1. To be able to release downstream-parent, it would have to have
> the
> >>>>>> proper configuration, specifically for the release and gpg maven
> >>>>>> plugins, that comes actually from the org.apache:apache:17 parent.
> >>>>>> 2. Consequently, the downstream parent should have either
> >>>>>> org.apache:apache:17 or even better
> >>>>>> org.apache.brooklyn:brooklyn-parent
> >>>>>> as a parent.
> >>>>>> 3. The downstream-parent is only used in the quickstart archetype.
> >>>>>>
> >>>>>> There is questionable value in having a downstream-parent that users
> >>>>>> would have to change anyway if it caries the apache scp and release
> >>>>>> configurations that wouldn't apply for a user's project.
> >>>>>>
> >>>>>> The only 2 solutions I can think of are to:
> >>>>>> a. Get rid of the downstream parent and move all the necessary
> >>>>>> incantations in the quickstart archetype.
> >>>>>> b. Transform the downstream-parent (and maybe come up with a better
> >>>> name
> >>>>>> for it) into a <scope>import</scope> pom [1].
> >>>>>>
> >>>>>> I think this is a blocker for the release.
> >>>>>>
> >>>>>> Thoughts?
> >>>>>> Hadrian
> >>>>>>
> >>>>>> [1]
> >>>>>>
> >>>>
> https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Importing_Dependencies
> >>>>
> >>>>>>
> >>>>>> On 06/27/2015 04:05 AM, Andrea Turli wrote:
> >>>>>>> Thanks Hadrian,
> >>>>>>>
> >>>>>>> I've also found this one while googling for another project [1], so
> >>>>>>> either
> >>>>>>> Apache parent or nothing should fix the issue.
> >>>>>>>
> >>>>>>> HTH,
> >>>>>>> Andrea
> >>>>>>>
> >>>>>>> [1]:
> >>>>>>>
> >>>>
> http://central.sonatype.org/pages/apache-maven.html#deprecated-oss-parent
> >>>>
> >>>>>>> On Sat, 27 Jun 2015 at 05:58 Hadrian Zbarcea <hz...@gmail.com>
> >>>> wrote:
> >>>>>>>> First thing, the <parent> for the brooklyn-downstream-parent
> should
> >>>>>>>> not be:
> >>>>>>>> <parent>
> >>>>>>>> <groupId>org.sonatype.oss</groupId>
> >>>>>>>> <artifactId>oss-parent</artifactId>
> >>>>>>>> <version>9</version>
> >>>>>>>> </parent>
> >>>>>>>>
> >>>>>>>> but the apache parent ultimately. I think this should completely
> >>>> resolve
> >>>>>>>> the problem. It's a bit late here to test, I'll do it tomorrow.
> >>>>>>>>
> >>>>>>>> Cheers,
> >>>>>>>> Hadrian
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On 06/26/2015 11:35 PM, Hadrian Zbarcea wrote:
> >>>>>>>>> I did try a dryRun myself and did encounter a problem with the
> >>>>>>>>> brooklyn-downstream-parent, but of a different nature
> >>>>>>>>> "'parent.relativePath' points at wrong local POM", but I suspect
> >>>> there
> >>>>>>>>> more issues there. From my experience releasing other projects, I
> >>>>>>>>> try to
> >>>>>>>>> first remove relevant branches from my local maven repo before
> >>>>>>>>> preparing
> >>>>>>>>> a release.
> >>>>>>>>>
> >>>>>>>>> I will look at it during the weekend. Somebody should revert the
> >>>>>>>>> version
> >>>>>>>>> back from 0.8.0-SNAPSHOT though.
> >>>>>>>>>
> >>>>>>>>> Cheers,
> >>>>>>>>> Hadrian
> >>>>>>>>>
> >>>>>>>>> On 06/26/2015 04:53 PM, Richard Downer wrote:
> >>>>>>>>>> So we got all the source code lined up today, and the release
> >>>> branch
> >>>>>>>>>> made.
> >>>>>>>>>> Everything was going very promisingly until I tried to close the
> >>>> Nexus
> >>>>>>>>>> repository to publish the artifacts and got a rule violation
> >>>>>>>>>> error.
> >>>>>>>>>>
> >>>>>>>>>> I'll have a look at fixing the problem and re-starting the
> >>>>>>>>>> release
> >>>> on
> >>>>>>>>>> Monday (unfortunately I won't have any availability to look at
> >>>>>>>>>> this
> >>>>>>>>>> over
> >>>>>>>>>> the weekend).
> >>>>>>>>>>
> >>>>>>>>>> In the meantime if anyone is looking for something to do over
> the
> >>>>>>>>>> weekend,
> >>>>>>>>>> the exact failure Nexus reported was:
> >>>>>>>>>>
> >>>>>>>>>> Missing Signature:
> >>>>>>>>>>
> >>>>
> '/org/apache/brooklyn/brooklyn-downstream-parent/0.7.0-incubating/brooklyn-downstream-parent-0.7.0-incubating.pom.asc'
> >>>>
> >>>>>>>>>> does not exist for
> >>>> 'brooklyn-downstream-parent-0.7.0-incubating.pom'.
> >>>>>>>>>> Everything else has a .pom.asc except downstream-parent so it
> >>>>>>>>>> seems
> >>>>>>>>>> there's
> >>>>>>>>>> something special about this project.
> >>>>>>>>>>
> >>>>>>>>>> Richard.
> >>>>>>>>>>
> >>>>
> >>>> --
> >>>> Cloudsoft Corporation Limited, Registered in Scotland No: SC349230.
> >>>> Registered Office: 13 Dryden Place, Edinburgh, EH9 1RP
> >>>>
> >>>> This e-mail message is confidential and for use by the addressee
> >>>> only. If
> >>>> the message is received by anyone other than the addressee, please
> >>>> return
> >>>> the message to the sender by replying to it and then delete the
> message
> >>>> from your computer. Internet e-mails are not necessarily secure.
> >>>> Cloudsoft
> >>>> Corporation Limited does not accept responsibility for changes made to
> >>>> this
> >>>> message after it was sent.
> >>>>
> >>>> Whilst all reasonable care has been taken to avoid the transmission of
> >>>> viruses, it is the responsibility of the recipient to ensure that the
> >>>> onward transmission, opening or use of this message and any
> attachments
> >>>> will not adversely affect its systems or data. No responsibility is
> >>>> accepted by Cloudsoft Corporation Limited in this regard and the
> >>>> recipient
> >>>> should carry out such virus and other checks as it considers
> >>>> appropriate.
> >>>>
> >
> >
>
Re: No 0.7.0-rc1 release today :(
Posted by Hadrian Zbarcea <hz...@gmail.com>.
It should be a trivial port, nothing specific to 0.8.0. Once the PR is
merged I can create another PR.
Cheers,
Hadrian
On 07/14/2015 05:07 AM, Aled Sage wrote:
> +1 for changing package name *after* the 0.7.0 release.
>
> I propose:
>
> * Release 0.7.0 with the existing package name
> (so that users have a stable (not milestone) release that they can
> use with confidence with minimal effort).
> * Work towards a 1.0:
> o clear any PR backlog
> o change the package names in master
> o document and thoroughly test the upgrade process from 0.7.0 to 1.0
> (explicitly *not* support any other upgrade paths, such as
> 0.7.0-M2 to 1.0, etc)
> o see what other features / fixes the community demand/want in a
> 1.0 release.
>
> ---
> For version number, I also favour sticking with 0.7.0.
>
> Of the two options for that:
>
> 1. backport changes to the 0.7.x branch, or
> 2. delete + recreate that to incorporate all code that is currently in
> master, but reverting version number to 0.7.0...
>
> I prefer the backport option, if that's not too hard technically.
>
> Aled
>
>
> On 14/07/2015 09:13, Richard Downer wrote:
>> On the subject of changing the Java package name (which I forgot to
>> mention) - yes this is something that will need to be done and we have
>> discussed this previously. The decisions was that the in-development
>> version of 0.7.0 would *not* have this change, but that it would be done
>> for 0.8.0.
>>
>> 0.7.0 has been brewing for a long time and I don't think there's the
>> appetite to do this right now. It's a major change, it would break our
>> user's code (which would be unfair on those that have been using
>> 0.7.0-M2)
>> and I've no doubt it would take weeks to fully shake out all the bugs
>> from
>> that kind of change. Meanwhile our users are clamouring for a 0.7.0
>> release as soon as we can :-)
>>
>> Once we've got 0.7.0 released then we'll kick off 0.8.0 development
>> proper
>> and have a discussion about what changes we want to include.
>>
>> Richard.
>>
>>
>> On Tue, 14 Jul 2015 at 09:03 Richard Downer <ri...@apache.org> wrote:
>>
>>> Hadrian, thanks very much for your efforts on this release blocker.
>>>
>>> I'm now back from vacation - I think that Sam is very busy this week so
>>> I'll put the Release Manager hat back on again and get an rc1 done
>>> today.
>>>
>>> Along with Svet I'm also in favour of option 1 - we have a release
>>> branch
>>> ready and we've already prepped some downstream customers to prepare for
>>> 0.7.0-final, so I'm not keen to change the version. I'm assuming that
>>> apart
>>> from the 0.7.0/0.8.0 difference, your changes should backport cleanly to
>>> the release branch.
>>>
>>> Should I be mistaken about the difficulty of this, then I will change my
>>> mind :-)
>>>
>>> Thanks again Hadrian and everyone else who has been looking at this
>>> problem.
>>>
>>> Richard.
>>>
>>>
>>> On Tue, 14 Jul 2015 at 08:58 Svetoslav Neykov <
>>> svetoslav.neykov@cloudsoftcorp.com> wrote:
>>>
>>>> I am for 1). As far as I know there's already a release branch with
>>>> some
>>>> backports. Another option is:
>>>>
>>>> 3. Create a 0.7.0 release off of the current master by changing back
>>>> the
>>>> version.
>>>>
>>>> Changing the package name should be done sooner rather than later, but
>>>> requires *very* careful planning due to:
>>>> * The need to keep backwards compatibility for existing persistence
>>>> stores. I'd prefer to have
>>>> https://github.com/apache/incubator-brooklyn/pull/738 <
>>>> https://github.com/apache/incubator-brooklyn/pull/738> merged before
>>>> attempting it.
>>>> * Existing 3rd party blueprints better still be usable after the
>>>> change, though this doesn't seem possible.
>>>>
>>>> Svet.
>>>>
>>>>
>>>>> On 14.07.2015 г., at 5:40, Hadrian Zbarcea <hz...@gmail.com> wrote:
>>>>>
>>>>> My proposed changes to unblock the release are now complete [1]. They
>>>> are done however on the master, which leaves us with one of the
>>>> following
>>>> options (if I am not missing something)
>>>>> 1. Backport to a 0.7.0-Mxxx branch
>>>>> 2. Abandon 0.7.0-Mxxx and release at 0.8.0
>>>>>
>>>>> While either work, I somewhat prefer moving on with #2 as the simplest
>>>> solution.
>>>>> Another thought is that migrating packages from brooklyn.* to
>>>> org.apache.brooklyn.* will be necessary at some point. I suspect
>>>> best would
>>>> be to do it now before a release.
>>>>> Thoughts?
>>>>> Hadrian
>>>>>
>>>>> [1] https://github.com/apache/incubator-brooklyn/pull/737
>>>>>
>>>>>
>>>>> On 06/27/2015 09:09 PM, Hadrian Zbarcea wrote:
>>>>>> This is not an easy one and imho would require some community choice
>>>>>> before implementing a solution.
>>>>>>
>>>>>> 1. To be able to release downstream-parent, it would have to have the
>>>>>> proper configuration, specifically for the release and gpg maven
>>>>>> plugins, that comes actually from the org.apache:apache:17 parent.
>>>>>> 2. Consequently, the downstream parent should have either
>>>>>> org.apache:apache:17 or even better
>>>>>> org.apache.brooklyn:brooklyn-parent
>>>>>> as a parent.
>>>>>> 3. The downstream-parent is only used in the quickstart archetype.
>>>>>>
>>>>>> There is questionable value in having a downstream-parent that users
>>>>>> would have to change anyway if it caries the apache scp and release
>>>>>> configurations that wouldn't apply for a user's project.
>>>>>>
>>>>>> The only 2 solutions I can think of are to:
>>>>>> a. Get rid of the downstream parent and move all the necessary
>>>>>> incantations in the quickstart archetype.
>>>>>> b. Transform the downstream-parent (and maybe come up with a better
>>>> name
>>>>>> for it) into a <scope>import</scope> pom [1].
>>>>>>
>>>>>> I think this is a blocker for the release.
>>>>>>
>>>>>> Thoughts?
>>>>>> Hadrian
>>>>>>
>>>>>> [1]
>>>>>>
>>>> https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Importing_Dependencies
>>>>
>>>>>>
>>>>>> On 06/27/2015 04:05 AM, Andrea Turli wrote:
>>>>>>> Thanks Hadrian,
>>>>>>>
>>>>>>> I've also found this one while googling for another project [1], so
>>>>>>> either
>>>>>>> Apache parent or nothing should fix the issue.
>>>>>>>
>>>>>>> HTH,
>>>>>>> Andrea
>>>>>>>
>>>>>>> [1]:
>>>>>>>
>>>> http://central.sonatype.org/pages/apache-maven.html#deprecated-oss-parent
>>>>
>>>>>>> On Sat, 27 Jun 2015 at 05:58 Hadrian Zbarcea <hz...@gmail.com>
>>>> wrote:
>>>>>>>> First thing, the <parent> for the brooklyn-downstream-parent should
>>>>>>>> not be:
>>>>>>>> <parent>
>>>>>>>> <groupId>org.sonatype.oss</groupId>
>>>>>>>> <artifactId>oss-parent</artifactId>
>>>>>>>> <version>9</version>
>>>>>>>> </parent>
>>>>>>>>
>>>>>>>> but the apache parent ultimately. I think this should completely
>>>> resolve
>>>>>>>> the problem. It's a bit late here to test, I'll do it tomorrow.
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Hadrian
>>>>>>>>
>>>>>>>>
>>>>>>>> On 06/26/2015 11:35 PM, Hadrian Zbarcea wrote:
>>>>>>>>> I did try a dryRun myself and did encounter a problem with the
>>>>>>>>> brooklyn-downstream-parent, but of a different nature
>>>>>>>>> "'parent.relativePath' points at wrong local POM", but I suspect
>>>> there
>>>>>>>>> more issues there. From my experience releasing other projects, I
>>>>>>>>> try to
>>>>>>>>> first remove relevant branches from my local maven repo before
>>>>>>>>> preparing
>>>>>>>>> a release.
>>>>>>>>>
>>>>>>>>> I will look at it during the weekend. Somebody should revert the
>>>>>>>>> version
>>>>>>>>> back from 0.8.0-SNAPSHOT though.
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> Hadrian
>>>>>>>>>
>>>>>>>>> On 06/26/2015 04:53 PM, Richard Downer wrote:
>>>>>>>>>> So we got all the source code lined up today, and the release
>>>> branch
>>>>>>>>>> made.
>>>>>>>>>> Everything was going very promisingly until I tried to close the
>>>> Nexus
>>>>>>>>>> repository to publish the artifacts and got a rule violation
>>>>>>>>>> error.
>>>>>>>>>>
>>>>>>>>>> I'll have a look at fixing the problem and re-starting the
>>>>>>>>>> release
>>>> on
>>>>>>>>>> Monday (unfortunately I won't have any availability to look at
>>>>>>>>>> this
>>>>>>>>>> over
>>>>>>>>>> the weekend).
>>>>>>>>>>
>>>>>>>>>> In the meantime if anyone is looking for something to do over the
>>>>>>>>>> weekend,
>>>>>>>>>> the exact failure Nexus reported was:
>>>>>>>>>>
>>>>>>>>>> Missing Signature:
>>>>>>>>>>
>>>> '/org/apache/brooklyn/brooklyn-downstream-parent/0.7.0-incubating/brooklyn-downstream-parent-0.7.0-incubating.pom.asc'
>>>>
>>>>>>>>>> does not exist for
>>>> 'brooklyn-downstream-parent-0.7.0-incubating.pom'.
>>>>>>>>>> Everything else has a .pom.asc except downstream-parent so it
>>>>>>>>>> seems
>>>>>>>>>> there's
>>>>>>>>>> something special about this project.
>>>>>>>>>>
>>>>>>>>>> Richard.
>>>>>>>>>>
>>>>
>>>> --
>>>> Cloudsoft Corporation Limited, Registered in Scotland No: SC349230.
>>>> Registered Office: 13 Dryden Place, Edinburgh, EH9 1RP
>>>>
>>>> This e-mail message is confidential and for use by the addressee
>>>> only. If
>>>> the message is received by anyone other than the addressee, please
>>>> return
>>>> the message to the sender by replying to it and then delete the message
>>>> from your computer. Internet e-mails are not necessarily secure.
>>>> Cloudsoft
>>>> Corporation Limited does not accept responsibility for changes made to
>>>> this
>>>> message after it was sent.
>>>>
>>>> Whilst all reasonable care has been taken to avoid the transmission of
>>>> viruses, it is the responsibility of the recipient to ensure that the
>>>> onward transmission, opening or use of this message and any attachments
>>>> will not adversely affect its systems or data. No responsibility is
>>>> accepted by Cloudsoft Corporation Limited in this regard and the
>>>> recipient
>>>> should carry out such virus and other checks as it considers
>>>> appropriate.
>>>>
>
>
Re: No 0.7.0-rc1 release today :(
Posted by Aled Sage <al...@gmail.com>.
+1 for changing package name *after* the 0.7.0 release.
I propose:
* Release 0.7.0 with the existing package name
(so that users have a stable (not milestone) release that they can
use with confidence with minimal effort).
* Work towards a 1.0:
o clear any PR backlog
o change the package names in master
o document and thoroughly test the upgrade process from 0.7.0 to 1.0
(explicitly *not* support any other upgrade paths, such as
0.7.0-M2 to 1.0, etc)
o see what other features / fixes the community demand/want in a
1.0 release.
---
For version number, I also favour sticking with 0.7.0.
Of the two options for that:
1. backport changes to the 0.7.x branch, or
2. delete + recreate that to incorporate all code that is currently in
master, but reverting version number to 0.7.0...
I prefer the backport option, if that's not too hard technically.
Aled
On 14/07/2015 09:13, Richard Downer wrote:
> On the subject of changing the Java package name (which I forgot to
> mention) - yes this is something that will need to be done and we have
> discussed this previously. The decisions was that the in-development
> version of 0.7.0 would *not* have this change, but that it would be done
> for 0.8.0.
>
> 0.7.0 has been brewing for a long time and I don't think there's the
> appetite to do this right now. It's a major change, it would break our
> user's code (which would be unfair on those that have been using 0.7.0-M2)
> and I've no doubt it would take weeks to fully shake out all the bugs from
> that kind of change. Meanwhile our users are clamouring for a 0.7.0
> release as soon as we can :-)
>
> Once we've got 0.7.0 released then we'll kick off 0.8.0 development proper
> and have a discussion about what changes we want to include.
>
> Richard.
>
>
> On Tue, 14 Jul 2015 at 09:03 Richard Downer <ri...@apache.org> wrote:
>
>> Hadrian, thanks very much for your efforts on this release blocker.
>>
>> I'm now back from vacation - I think that Sam is very busy this week so
>> I'll put the Release Manager hat back on again and get an rc1 done today.
>>
>> Along with Svet I'm also in favour of option 1 - we have a release branch
>> ready and we've already prepped some downstream customers to prepare for
>> 0.7.0-final, so I'm not keen to change the version. I'm assuming that apart
>> from the 0.7.0/0.8.0 difference, your changes should backport cleanly to
>> the release branch.
>>
>> Should I be mistaken about the difficulty of this, then I will change my
>> mind :-)
>>
>> Thanks again Hadrian and everyone else who has been looking at this
>> problem.
>>
>> Richard.
>>
>>
>> On Tue, 14 Jul 2015 at 08:58 Svetoslav Neykov <
>> svetoslav.neykov@cloudsoftcorp.com> wrote:
>>
>>> I am for 1). As far as I know there's already a release branch with some
>>> backports. Another option is:
>>>
>>> 3. Create a 0.7.0 release off of the current master by changing back the
>>> version.
>>>
>>> Changing the package name should be done sooner rather than later, but
>>> requires *very* careful planning due to:
>>> * The need to keep backwards compatibility for existing persistence
>>> stores. I'd prefer to have
>>> https://github.com/apache/incubator-brooklyn/pull/738 <
>>> https://github.com/apache/incubator-brooklyn/pull/738> merged before
>>> attempting it.
>>> * Existing 3rd party blueprints better still be usable after the
>>> change, though this doesn't seem possible.
>>>
>>> Svet.
>>>
>>>
>>>> On 14.07.2015 г., at 5:40, Hadrian Zbarcea <hz...@gmail.com> wrote:
>>>>
>>>> My proposed changes to unblock the release are now complete [1]. They
>>> are done however on the master, which leaves us with one of the following
>>> options (if I am not missing something)
>>>> 1. Backport to a 0.7.0-Mxxx branch
>>>> 2. Abandon 0.7.0-Mxxx and release at 0.8.0
>>>>
>>>> While either work, I somewhat prefer moving on with #2 as the simplest
>>> solution.
>>>> Another thought is that migrating packages from brooklyn.* to
>>> org.apache.brooklyn.* will be necessary at some point. I suspect best would
>>> be to do it now before a release.
>>>> Thoughts?
>>>> Hadrian
>>>>
>>>> [1] https://github.com/apache/incubator-brooklyn/pull/737
>>>>
>>>>
>>>> On 06/27/2015 09:09 PM, Hadrian Zbarcea wrote:
>>>>> This is not an easy one and imho would require some community choice
>>>>> before implementing a solution.
>>>>>
>>>>> 1. To be able to release downstream-parent, it would have to have the
>>>>> proper configuration, specifically for the release and gpg maven
>>>>> plugins, that comes actually from the org.apache:apache:17 parent.
>>>>> 2. Consequently, the downstream parent should have either
>>>>> org.apache:apache:17 or even better org.apache.brooklyn:brooklyn-parent
>>>>> as a parent.
>>>>> 3. The downstream-parent is only used in the quickstart archetype.
>>>>>
>>>>> There is questionable value in having a downstream-parent that users
>>>>> would have to change anyway if it caries the apache scp and release
>>>>> configurations that wouldn't apply for a user's project.
>>>>>
>>>>> The only 2 solutions I can think of are to:
>>>>> a. Get rid of the downstream parent and move all the necessary
>>>>> incantations in the quickstart archetype.
>>>>> b. Transform the downstream-parent (and maybe come up with a better
>>> name
>>>>> for it) into a <scope>import</scope> pom [1].
>>>>>
>>>>> I think this is a blocker for the release.
>>>>>
>>>>> Thoughts?
>>>>> Hadrian
>>>>>
>>>>> [1]
>>>>>
>>> https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Importing_Dependencies
>>>>>
>>>>> On 06/27/2015 04:05 AM, Andrea Turli wrote:
>>>>>> Thanks Hadrian,
>>>>>>
>>>>>> I've also found this one while googling for another project [1], so
>>>>>> either
>>>>>> Apache parent or nothing should fix the issue.
>>>>>>
>>>>>> HTH,
>>>>>> Andrea
>>>>>>
>>>>>> [1]:
>>>>>>
>>> http://central.sonatype.org/pages/apache-maven.html#deprecated-oss-parent
>>>>>> On Sat, 27 Jun 2015 at 05:58 Hadrian Zbarcea <hz...@gmail.com>
>>> wrote:
>>>>>>> First thing, the <parent> for the brooklyn-downstream-parent should
>>>>>>> not be:
>>>>>>> <parent>
>>>>>>> <groupId>org.sonatype.oss</groupId>
>>>>>>> <artifactId>oss-parent</artifactId>
>>>>>>> <version>9</version>
>>>>>>> </parent>
>>>>>>>
>>>>>>> but the apache parent ultimately. I think this should completely
>>> resolve
>>>>>>> the problem. It's a bit late here to test, I'll do it tomorrow.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Hadrian
>>>>>>>
>>>>>>>
>>>>>>> On 06/26/2015 11:35 PM, Hadrian Zbarcea wrote:
>>>>>>>> I did try a dryRun myself and did encounter a problem with the
>>>>>>>> brooklyn-downstream-parent, but of a different nature
>>>>>>>> "'parent.relativePath' points at wrong local POM", but I suspect
>>> there
>>>>>>>> more issues there. From my experience releasing other projects, I
>>>>>>>> try to
>>>>>>>> first remove relevant branches from my local maven repo before
>>>>>>>> preparing
>>>>>>>> a release.
>>>>>>>>
>>>>>>>> I will look at it during the weekend. Somebody should revert the
>>>>>>>> version
>>>>>>>> back from 0.8.0-SNAPSHOT though.
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Hadrian
>>>>>>>>
>>>>>>>> On 06/26/2015 04:53 PM, Richard Downer wrote:
>>>>>>>>> So we got all the source code lined up today, and the release
>>> branch
>>>>>>>>> made.
>>>>>>>>> Everything was going very promisingly until I tried to close the
>>> Nexus
>>>>>>>>> repository to publish the artifacts and got a rule violation error.
>>>>>>>>>
>>>>>>>>> I'll have a look at fixing the problem and re-starting the release
>>> on
>>>>>>>>> Monday (unfortunately I won't have any availability to look at this
>>>>>>>>> over
>>>>>>>>> the weekend).
>>>>>>>>>
>>>>>>>>> In the meantime if anyone is looking for something to do over the
>>>>>>>>> weekend,
>>>>>>>>> the exact failure Nexus reported was:
>>>>>>>>>
>>>>>>>>> Missing Signature:
>>>>>>>>>
>>> '/org/apache/brooklyn/brooklyn-downstream-parent/0.7.0-incubating/brooklyn-downstream-parent-0.7.0-incubating.pom.asc'
>>>>>>>>> does not exist for
>>> 'brooklyn-downstream-parent-0.7.0-incubating.pom'.
>>>>>>>>> Everything else has a .pom.asc except downstream-parent so it seems
>>>>>>>>> there's
>>>>>>>>> something special about this project.
>>>>>>>>>
>>>>>>>>> Richard.
>>>>>>>>>
>>>
>>> --
>>> Cloudsoft Corporation Limited, Registered in Scotland No: SC349230.
>>> Registered Office: 13 Dryden Place, Edinburgh, EH9 1RP
>>>
>>> This e-mail message is confidential and for use by the addressee only. If
>>> the message is received by anyone other than the addressee, please return
>>> the message to the sender by replying to it and then delete the message
>>> from your computer. Internet e-mails are not necessarily secure. Cloudsoft
>>> Corporation Limited does not accept responsibility for changes made to
>>> this
>>> message after it was sent.
>>>
>>> Whilst all reasonable care has been taken to avoid the transmission of
>>> viruses, it is the responsibility of the recipient to ensure that the
>>> onward transmission, opening or use of this message and any attachments
>>> will not adversely affect its systems or data. No responsibility is
>>> accepted by Cloudsoft Corporation Limited in this regard and the recipient
>>> should carry out such virus and other checks as it considers appropriate.
>>>
Re: No 0.7.0-rc1 release today :(
Posted by Richard Downer <ri...@apache.org>.
On the subject of changing the Java package name (which I forgot to
mention) - yes this is something that will need to be done and we have
discussed this previously. The decisions was that the in-development
version of 0.7.0 would *not* have this change, but that it would be done
for 0.8.0.
0.7.0 has been brewing for a long time and I don't think there's the
appetite to do this right now. It's a major change, it would break our
user's code (which would be unfair on those that have been using 0.7.0-M2)
and I've no doubt it would take weeks to fully shake out all the bugs from
that kind of change. Meanwhile our users are clamouring for a 0.7.0
release as soon as we can :-)
Once we've got 0.7.0 released then we'll kick off 0.8.0 development proper
and have a discussion about what changes we want to include.
Richard.
On Tue, 14 Jul 2015 at 09:03 Richard Downer <ri...@apache.org> wrote:
> Hadrian, thanks very much for your efforts on this release blocker.
>
> I'm now back from vacation - I think that Sam is very busy this week so
> I'll put the Release Manager hat back on again and get an rc1 done today.
>
> Along with Svet I'm also in favour of option 1 - we have a release branch
> ready and we've already prepped some downstream customers to prepare for
> 0.7.0-final, so I'm not keen to change the version. I'm assuming that apart
> from the 0.7.0/0.8.0 difference, your changes should backport cleanly to
> the release branch.
>
> Should I be mistaken about the difficulty of this, then I will change my
> mind :-)
>
> Thanks again Hadrian and everyone else who has been looking at this
> problem.
>
> Richard.
>
>
> On Tue, 14 Jul 2015 at 08:58 Svetoslav Neykov <
> svetoslav.neykov@cloudsoftcorp.com> wrote:
>
>> I am for 1). As far as I know there's already a release branch with some
>> backports. Another option is:
>>
>> 3. Create a 0.7.0 release off of the current master by changing back the
>> version.
>>
>> Changing the package name should be done sooner rather than later, but
>> requires *very* careful planning due to:
>> * The need to keep backwards compatibility for existing persistence
>> stores. I'd prefer to have
>> https://github.com/apache/incubator-brooklyn/pull/738 <
>> https://github.com/apache/incubator-brooklyn/pull/738> merged before
>> attempting it.
>> * Existing 3rd party blueprints better still be usable after the
>> change, though this doesn't seem possible.
>>
>> Svet.
>>
>>
>> > On 14.07.2015 г., at 5:40, Hadrian Zbarcea <hz...@gmail.com> wrote:
>> >
>> > My proposed changes to unblock the release are now complete [1]. They
>> are done however on the master, which leaves us with one of the following
>> options (if I am not missing something)
>> >
>> > 1. Backport to a 0.7.0-Mxxx branch
>> > 2. Abandon 0.7.0-Mxxx and release at 0.8.0
>> >
>> > While either work, I somewhat prefer moving on with #2 as the simplest
>> solution.
>> >
>> > Another thought is that migrating packages from brooklyn.* to
>> org.apache.brooklyn.* will be necessary at some point. I suspect best would
>> be to do it now before a release.
>> >
>> > Thoughts?
>> > Hadrian
>> >
>> > [1] https://github.com/apache/incubator-brooklyn/pull/737
>> >
>> >
>> > On 06/27/2015 09:09 PM, Hadrian Zbarcea wrote:
>> >> This is not an easy one and imho would require some community choice
>> >> before implementing a solution.
>> >>
>> >> 1. To be able to release downstream-parent, it would have to have the
>> >> proper configuration, specifically for the release and gpg maven
>> >> plugins, that comes actually from the org.apache:apache:17 parent.
>> >> 2. Consequently, the downstream parent should have either
>> >> org.apache:apache:17 or even better org.apache.brooklyn:brooklyn-parent
>> >> as a parent.
>> >> 3. The downstream-parent is only used in the quickstart archetype.
>> >>
>> >> There is questionable value in having a downstream-parent that users
>> >> would have to change anyway if it caries the apache scp and release
>> >> configurations that wouldn't apply for a user's project.
>> >>
>> >> The only 2 solutions I can think of are to:
>> >> a. Get rid of the downstream parent and move all the necessary
>> >> incantations in the quickstart archetype.
>> >> b. Transform the downstream-parent (and maybe come up with a better
>> name
>> >> for it) into a <scope>import</scope> pom [1].
>> >>
>> >> I think this is a blocker for the release.
>> >>
>> >> Thoughts?
>> >> Hadrian
>> >>
>> >> [1]
>> >>
>> https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Importing_Dependencies
>> >>
>> >>
>> >> On 06/27/2015 04:05 AM, Andrea Turli wrote:
>> >>> Thanks Hadrian,
>> >>>
>> >>> I've also found this one while googling for another project [1], so
>> >>> either
>> >>> Apache parent or nothing should fix the issue.
>> >>>
>> >>> HTH,
>> >>> Andrea
>> >>>
>> >>> [1]:
>> >>>
>> http://central.sonatype.org/pages/apache-maven.html#deprecated-oss-parent
>> >>>
>> >>> On Sat, 27 Jun 2015 at 05:58 Hadrian Zbarcea <hz...@gmail.com>
>> wrote:
>> >>>
>> >>>> First thing, the <parent> for the brooklyn-downstream-parent should
>> >>>> not be:
>> >>>> <parent>
>> >>>> <groupId>org.sonatype.oss</groupId>
>> >>>> <artifactId>oss-parent</artifactId>
>> >>>> <version>9</version>
>> >>>> </parent>
>> >>>>
>> >>>> but the apache parent ultimately. I think this should completely
>> resolve
>> >>>> the problem. It's a bit late here to test, I'll do it tomorrow.
>> >>>>
>> >>>> Cheers,
>> >>>> Hadrian
>> >>>>
>> >>>>
>> >>>> On 06/26/2015 11:35 PM, Hadrian Zbarcea wrote:
>> >>>>> I did try a dryRun myself and did encounter a problem with the
>> >>>>> brooklyn-downstream-parent, but of a different nature
>> >>>>> "'parent.relativePath' points at wrong local POM", but I suspect
>> there
>> >>>>> more issues there. From my experience releasing other projects, I
>> >>>>> try to
>> >>>>> first remove relevant branches from my local maven repo before
>> >>>>> preparing
>> >>>>> a release.
>> >>>>>
>> >>>>> I will look at it during the weekend. Somebody should revert the
>> >>>>> version
>> >>>>> back from 0.8.0-SNAPSHOT though.
>> >>>>>
>> >>>>> Cheers,
>> >>>>> Hadrian
>> >>>>>
>> >>>>> On 06/26/2015 04:53 PM, Richard Downer wrote:
>> >>>>>> So we got all the source code lined up today, and the release
>> branch
>> >>>>>> made.
>> >>>>>> Everything was going very promisingly until I tried to close the
>> Nexus
>> >>>>>> repository to publish the artifacts and got a rule violation error.
>> >>>>>>
>> >>>>>> I'll have a look at fixing the problem and re-starting the release
>> on
>> >>>>>> Monday (unfortunately I won't have any availability to look at this
>> >>>>>> over
>> >>>>>> the weekend).
>> >>>>>>
>> >>>>>> In the meantime if anyone is looking for something to do over the
>> >>>>>> weekend,
>> >>>>>> the exact failure Nexus reported was:
>> >>>>>>
>> >>>>>> Missing Signature:
>> >>>>>>
>> >>>>
>> '/org/apache/brooklyn/brooklyn-downstream-parent/0.7.0-incubating/brooklyn-downstream-parent-0.7.0-incubating.pom.asc'
>> >>>>
>> >>>>>>
>> >>>>>> does not exist for
>> 'brooklyn-downstream-parent-0.7.0-incubating.pom'.
>> >>>>>>
>> >>>>>> Everything else has a .pom.asc except downstream-parent so it seems
>> >>>>>> there's
>> >>>>>> something special about this project.
>> >>>>>>
>> >>>>>> Richard.
>> >>>>>>
>> >>>>
>> >>>
>>
>>
>> --
>> Cloudsoft Corporation Limited, Registered in Scotland No: SC349230.
>> Registered Office: 13 Dryden Place, Edinburgh, EH9 1RP
>>
>> This e-mail message is confidential and for use by the addressee only. If
>> the message is received by anyone other than the addressee, please return
>> the message to the sender by replying to it and then delete the message
>> from your computer. Internet e-mails are not necessarily secure. Cloudsoft
>> Corporation Limited does not accept responsibility for changes made to
>> this
>> message after it was sent.
>>
>> Whilst all reasonable care has been taken to avoid the transmission of
>> viruses, it is the responsibility of the recipient to ensure that the
>> onward transmission, opening or use of this message and any attachments
>> will not adversely affect its systems or data. No responsibility is
>> accepted by Cloudsoft Corporation Limited in this regard and the recipient
>> should carry out such virus and other checks as it considers appropriate.
>>
>
Re: No 0.7.0-rc1 release today :(
Posted by Richard Downer <ri...@apache.org>.
Hadrian, thanks very much for your efforts on this release blocker.
I'm now back from vacation - I think that Sam is very busy this week so
I'll put the Release Manager hat back on again and get an rc1 done today.
Along with Svet I'm also in favour of option 1 - we have a release branch
ready and we've already prepped some downstream customers to prepare for
0.7.0-final, so I'm not keen to change the version. I'm assuming that apart
from the 0.7.0/0.8.0 difference, your changes should backport cleanly to
the release branch.
Should I be mistaken about the difficulty of this, then I will change my
mind :-)
Thanks again Hadrian and everyone else who has been looking at this problem.
Richard.
On Tue, 14 Jul 2015 at 08:58 Svetoslav Neykov <
svetoslav.neykov@cloudsoftcorp.com> wrote:
> I am for 1). As far as I know there's already a release branch with some
> backports. Another option is:
>
> 3. Create a 0.7.0 release off of the current master by changing back the
> version.
>
> Changing the package name should be done sooner rather than later, but
> requires *very* careful planning due to:
> * The need to keep backwards compatibility for existing persistence
> stores. I'd prefer to have
> https://github.com/apache/incubator-brooklyn/pull/738 <
> https://github.com/apache/incubator-brooklyn/pull/738> merged before
> attempting it.
> * Existing 3rd party blueprints better still be usable after the change,
> though this doesn't seem possible.
>
> Svet.
>
>
> > On 14.07.2015 г., at 5:40, Hadrian Zbarcea <hz...@gmail.com> wrote:
> >
> > My proposed changes to unblock the release are now complete [1]. They
> are done however on the master, which leaves us with one of the following
> options (if I am not missing something)
> >
> > 1. Backport to a 0.7.0-Mxxx branch
> > 2. Abandon 0.7.0-Mxxx and release at 0.8.0
> >
> > While either work, I somewhat prefer moving on with #2 as the simplest
> solution.
> >
> > Another thought is that migrating packages from brooklyn.* to
> org.apache.brooklyn.* will be necessary at some point. I suspect best would
> be to do it now before a release.
> >
> > Thoughts?
> > Hadrian
> >
> > [1] https://github.com/apache/incubator-brooklyn/pull/737
> >
> >
> > On 06/27/2015 09:09 PM, Hadrian Zbarcea wrote:
> >> This is not an easy one and imho would require some community choice
> >> before implementing a solution.
> >>
> >> 1. To be able to release downstream-parent, it would have to have the
> >> proper configuration, specifically for the release and gpg maven
> >> plugins, that comes actually from the org.apache:apache:17 parent.
> >> 2. Consequently, the downstream parent should have either
> >> org.apache:apache:17 or even better org.apache.brooklyn:brooklyn-parent
> >> as a parent.
> >> 3. The downstream-parent is only used in the quickstart archetype.
> >>
> >> There is questionable value in having a downstream-parent that users
> >> would have to change anyway if it caries the apache scp and release
> >> configurations that wouldn't apply for a user's project.
> >>
> >> The only 2 solutions I can think of are to:
> >> a. Get rid of the downstream parent and move all the necessary
> >> incantations in the quickstart archetype.
> >> b. Transform the downstream-parent (and maybe come up with a better name
> >> for it) into a <scope>import</scope> pom [1].
> >>
> >> I think this is a blocker for the release.
> >>
> >> Thoughts?
> >> Hadrian
> >>
> >> [1]
> >>
> https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Importing_Dependencies
> >>
> >>
> >> On 06/27/2015 04:05 AM, Andrea Turli wrote:
> >>> Thanks Hadrian,
> >>>
> >>> I've also found this one while googling for another project [1], so
> >>> either
> >>> Apache parent or nothing should fix the issue.
> >>>
> >>> HTH,
> >>> Andrea
> >>>
> >>> [1]:
> >>>
> http://central.sonatype.org/pages/apache-maven.html#deprecated-oss-parent
> >>>
> >>> On Sat, 27 Jun 2015 at 05:58 Hadrian Zbarcea <hz...@gmail.com>
> wrote:
> >>>
> >>>> First thing, the <parent> for the brooklyn-downstream-parent should
> >>>> not be:
> >>>> <parent>
> >>>> <groupId>org.sonatype.oss</groupId>
> >>>> <artifactId>oss-parent</artifactId>
> >>>> <version>9</version>
> >>>> </parent>
> >>>>
> >>>> but the apache parent ultimately. I think this should completely
> resolve
> >>>> the problem. It's a bit late here to test, I'll do it tomorrow.
> >>>>
> >>>> Cheers,
> >>>> Hadrian
> >>>>
> >>>>
> >>>> On 06/26/2015 11:35 PM, Hadrian Zbarcea wrote:
> >>>>> I did try a dryRun myself and did encounter a problem with the
> >>>>> brooklyn-downstream-parent, but of a different nature
> >>>>> "'parent.relativePath' points at wrong local POM", but I suspect
> there
> >>>>> more issues there. From my experience releasing other projects, I
> >>>>> try to
> >>>>> first remove relevant branches from my local maven repo before
> >>>>> preparing
> >>>>> a release.
> >>>>>
> >>>>> I will look at it during the weekend. Somebody should revert the
> >>>>> version
> >>>>> back from 0.8.0-SNAPSHOT though.
> >>>>>
> >>>>> Cheers,
> >>>>> Hadrian
> >>>>>
> >>>>> On 06/26/2015 04:53 PM, Richard Downer wrote:
> >>>>>> So we got all the source code lined up today, and the release branch
> >>>>>> made.
> >>>>>> Everything was going very promisingly until I tried to close the
> Nexus
> >>>>>> repository to publish the artifacts and got a rule violation error.
> >>>>>>
> >>>>>> I'll have a look at fixing the problem and re-starting the release
> on
> >>>>>> Monday (unfortunately I won't have any availability to look at this
> >>>>>> over
> >>>>>> the weekend).
> >>>>>>
> >>>>>> In the meantime if anyone is looking for something to do over the
> >>>>>> weekend,
> >>>>>> the exact failure Nexus reported was:
> >>>>>>
> >>>>>> Missing Signature:
> >>>>>>
> >>>>
> '/org/apache/brooklyn/brooklyn-downstream-parent/0.7.0-incubating/brooklyn-downstream-parent-0.7.0-incubating.pom.asc'
> >>>>
> >>>>>>
> >>>>>> does not exist for
> 'brooklyn-downstream-parent-0.7.0-incubating.pom'.
> >>>>>>
> >>>>>> Everything else has a .pom.asc except downstream-parent so it seems
> >>>>>> there's
> >>>>>> something special about this project.
> >>>>>>
> >>>>>> Richard.
> >>>>>>
> >>>>
> >>>
>
>
> --
> Cloudsoft Corporation Limited, Registered in Scotland No: SC349230.
> Registered Office: 13 Dryden Place, Edinburgh, EH9 1RP
>
> This e-mail message is confidential and for use by the addressee only. If
> the message is received by anyone other than the addressee, please return
> the message to the sender by replying to it and then delete the message
> from your computer. Internet e-mails are not necessarily secure. Cloudsoft
> Corporation Limited does not accept responsibility for changes made to this
> message after it was sent.
>
> Whilst all reasonable care has been taken to avoid the transmission of
> viruses, it is the responsibility of the recipient to ensure that the
> onward transmission, opening or use of this message and any attachments
> will not adversely affect its systems or data. No responsibility is
> accepted by Cloudsoft Corporation Limited in this regard and the recipient
> should carry out such virus and other checks as it considers appropriate.
>
Re: No 0.7.0-rc1 release today :(
Posted by Svetoslav Neykov <sv...@cloudsoftcorp.com>.
I am for 1). As far as I know there's already a release branch with some backports. Another option is:
3. Create a 0.7.0 release off of the current master by changing back the version.
Changing the package name should be done sooner rather than later, but requires *very* careful planning due to:
* The need to keep backwards compatibility for existing persistence stores. I'd prefer to have https://github.com/apache/incubator-brooklyn/pull/738 <https://github.com/apache/incubator-brooklyn/pull/738> merged before attempting it.
* Existing 3rd party blueprints better still be usable after the change, though this doesn't seem possible.
Svet.
> On 14.07.2015 г., at 5:40, Hadrian Zbarcea <hz...@gmail.com> wrote:
>
> My proposed changes to unblock the release are now complete [1]. They are done however on the master, which leaves us with one of the following options (if I am not missing something)
>
> 1. Backport to a 0.7.0-Mxxx branch
> 2. Abandon 0.7.0-Mxxx and release at 0.8.0
>
> While either work, I somewhat prefer moving on with #2 as the simplest solution.
>
> Another thought is that migrating packages from brooklyn.* to org.apache.brooklyn.* will be necessary at some point. I suspect best would be to do it now before a release.
>
> Thoughts?
> Hadrian
>
> [1] https://github.com/apache/incubator-brooklyn/pull/737
>
>
> On 06/27/2015 09:09 PM, Hadrian Zbarcea wrote:
>> This is not an easy one and imho would require some community choice
>> before implementing a solution.
>>
>> 1. To be able to release downstream-parent, it would have to have the
>> proper configuration, specifically for the release and gpg maven
>> plugins, that comes actually from the org.apache:apache:17 parent.
>> 2. Consequently, the downstream parent should have either
>> org.apache:apache:17 or even better org.apache.brooklyn:brooklyn-parent
>> as a parent.
>> 3. The downstream-parent is only used in the quickstart archetype.
>>
>> There is questionable value in having a downstream-parent that users
>> would have to change anyway if it caries the apache scp and release
>> configurations that wouldn't apply for a user's project.
>>
>> The only 2 solutions I can think of are to:
>> a. Get rid of the downstream parent and move all the necessary
>> incantations in the quickstart archetype.
>> b. Transform the downstream-parent (and maybe come up with a better name
>> for it) into a <scope>import</scope> pom [1].
>>
>> I think this is a blocker for the release.
>>
>> Thoughts?
>> Hadrian
>>
>> [1]
>> https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Importing_Dependencies
>>
>>
>> On 06/27/2015 04:05 AM, Andrea Turli wrote:
>>> Thanks Hadrian,
>>>
>>> I've also found this one while googling for another project [1], so
>>> either
>>> Apache parent or nothing should fix the issue.
>>>
>>> HTH,
>>> Andrea
>>>
>>> [1]:
>>> http://central.sonatype.org/pages/apache-maven.html#deprecated-oss-parent
>>>
>>> On Sat, 27 Jun 2015 at 05:58 Hadrian Zbarcea <hz...@gmail.com> wrote:
>>>
>>>> First thing, the <parent> for the brooklyn-downstream-parent should
>>>> not be:
>>>> <parent>
>>>> <groupId>org.sonatype.oss</groupId>
>>>> <artifactId>oss-parent</artifactId>
>>>> <version>9</version>
>>>> </parent>
>>>>
>>>> but the apache parent ultimately. I think this should completely resolve
>>>> the problem. It's a bit late here to test, I'll do it tomorrow.
>>>>
>>>> Cheers,
>>>> Hadrian
>>>>
>>>>
>>>> On 06/26/2015 11:35 PM, Hadrian Zbarcea wrote:
>>>>> I did try a dryRun myself and did encounter a problem with the
>>>>> brooklyn-downstream-parent, but of a different nature
>>>>> "'parent.relativePath' points at wrong local POM", but I suspect there
>>>>> more issues there. From my experience releasing other projects, I
>>>>> try to
>>>>> first remove relevant branches from my local maven repo before
>>>>> preparing
>>>>> a release.
>>>>>
>>>>> I will look at it during the weekend. Somebody should revert the
>>>>> version
>>>>> back from 0.8.0-SNAPSHOT though.
>>>>>
>>>>> Cheers,
>>>>> Hadrian
>>>>>
>>>>> On 06/26/2015 04:53 PM, Richard Downer wrote:
>>>>>> So we got all the source code lined up today, and the release branch
>>>>>> made.
>>>>>> Everything was going very promisingly until I tried to close the Nexus
>>>>>> repository to publish the artifacts and got a rule violation error.
>>>>>>
>>>>>> I'll have a look at fixing the problem and re-starting the release on
>>>>>> Monday (unfortunately I won't have any availability to look at this
>>>>>> over
>>>>>> the weekend).
>>>>>>
>>>>>> In the meantime if anyone is looking for something to do over the
>>>>>> weekend,
>>>>>> the exact failure Nexus reported was:
>>>>>>
>>>>>> Missing Signature:
>>>>>>
>>>> '/org/apache/brooklyn/brooklyn-downstream-parent/0.7.0-incubating/brooklyn-downstream-parent-0.7.0-incubating.pom.asc'
>>>>
>>>>>>
>>>>>> does not exist for 'brooklyn-downstream-parent-0.7.0-incubating.pom'.
>>>>>>
>>>>>> Everything else has a .pom.asc except downstream-parent so it seems
>>>>>> there's
>>>>>> something special about this project.
>>>>>>
>>>>>> Richard.
>>>>>>
>>>>
>>>
--
Cloudsoft Corporation Limited, Registered in Scotland No: SC349230.
Registered Office: 13 Dryden Place, Edinburgh, EH9 1RP
This e-mail message is confidential and for use by the addressee only. If
the message is received by anyone other than the addressee, please return
the message to the sender by replying to it and then delete the message
from your computer. Internet e-mails are not necessarily secure. Cloudsoft
Corporation Limited does not accept responsibility for changes made to this
message after it was sent.
Whilst all reasonable care has been taken to avoid the transmission of
viruses, it is the responsibility of the recipient to ensure that the
onward transmission, opening or use of this message and any attachments
will not adversely affect its systems or data. No responsibility is
accepted by Cloudsoft Corporation Limited in this regard and the recipient
should carry out such virus and other checks as it considers appropriate.