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 < [email protected]> 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 <[email protected]> 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 <[email protected]> > 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. >
