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