Hi Jeremy, This is what mvn release:prepare does. It creates a tag in SVN. If the release doesn't succeed for some reason later on the tag stays left behind.
When I'll re-spin the release I'll use 1.0.1. There are no 1.0.0 artifacts available in maven. I personally don't see the need to remove tags for failed releases as I think it's messy. Just use the next number as numbers are cheap. David On 13 July 2015 at 14:32, Jeremy Hughes <[email protected]> wrote: > Hi David, it seems the async release that was cancelled has ended up > in the aries/tags dir. Is this by mistake? I don't think it's an issue > for now, but when you do the 1.0.0 release I think you'll need to > remove that tag. I guess the 'cancelling a release' didn't undo the > tag. > > On 7 July 2015 at 11:31, David Bosschaert <[email protected]> wrote: >> Ok - then let's cancel the vote. >> >> I should be able to restart it some time next week. >> >> On 7 July 2015 at 09:42, Timothy Ward <[email protected]> wrote: >>> Hi David, >>> >>> I think I’m right in saying that the Apache release process needs the >>> source headers for approval. :( >>> >>> https://www.apache.org/dev/release.html#full-copy-for-each-source-file >>> >>> Regards, >>> >>> Tim >>> >>>> On 6 Jul 2015, at 08:27, David Bosschaert <[email protected]> >>>> wrote: >>>> >>>> Hi Tim, >>>> >>>> I think that's pretty much always how it happens for something that is >>>> in the process of being released. You can add the staging repository >>>> to your maven repos and then you should be able to rebuild from >>>> sources. Does someone have a better way of doing this? >>>> >>>> If people think I should re-spin the release because of the headers, >>>> let me know. >>>> >>>> David >>>> >>>> On 4 July 2015 at 00:23, Timothy Ward <[email protected]> wrote: >>>>> Hi, >>>>> >>>>> So the good news is that the release versions all pass the relevant >>>>> compliance tests for their respective specifications, but I have noted >>>>> two issues… >>>>> >>>>> I’m unable to build from source unless I re-version all of the bundles to >>>>> 1.0.0-SNAPSHOT and do a mvn clean install first. If I fail to do this >>>>> then the version checker fails the build. Once I have 1.0.0-SNAPSHOT >>>>> versions in my local repository then everything works fine. >>>>> The RAT check fails because the source files are missing Apache licence >>>>> headers (my fault originally). This applies to the Promise API >>>>> implementation and the Async API and Async Impl bundles. I’m not sure >>>>> what the policy is for licence headers on the classes/interfaces in the >>>>> org.osgi.xxx namespace. >>>>> >>>>> In summary, I’m +1 for the binaries, which work and contain all of the >>>>> necessary licence info. I’m not sure if we need to respin for the >>>>> source/build issues though. >>>>> >>>>> Regards, >>>>> >>>>> Tim >>>>> >>>>>> On 3 Jul 2015, at 16:42, Sergey Beryozkin <[email protected]> wrote: >>>>>> >>>>>> +1 >>>>>> Sergey >>>>>> On 03/07/15 12:55, [email protected] wrote: >>>>>>> Here's my +1 >>>>>>> >>>>>>> David >>>>>>> >>>>>>> On 3 July 2015 at 11:36, <[email protected]> wrote: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> I'm calling a vote on the first release of the Aries Asynchronous OSGi >>>>>>>> Services implementation. This implements the OSGi Asynchronous >>>>>>>> Services specification (chapter 138) and the OSGi Promises >>>>>>>> specification (chapter 705) of the upcoming OSGi Enterprise R6 >>>>>>>> specifications, which are available as proposed final draft [1]. >>>>>>>> >>>>>>>> Staging repository: >>>>>>>> https://repository.apache.org/content/repositories/orgapachearies-1031 >>>>>>>> >>>>>>>> For details on getting started see >>>>>>>> http://aries.apache.org/modules/async-svcs.html >>>>>>>> Kudos to Tim Ward for providing this implementation. >>>>>>>> >>>>>>>> Please vote: >>>>>>>> >>>>>>>> +1 Approve the release >>>>>>>> -1 Do not approve the release (please explain why) >>>>>>>> >>>>>>>> This vote will be open for at least 72 hours. >>>>>>>> >>>>>>>> Best regards, >>>>>>>> >>>>>>>> David Bosschaert >>>>>>>> >>>>>>>> [1] http://www.osgi.org/Specifications/Drafts >>>>>> >>>>> >>>
