+1 to creation of a branch on cutting first RC, this will require update to the release procedure doc that I followed. This can save some trouble. Also we can have the build_asf do a git push, of the versioning commits generated by it, automatically if it is not a dry run. The problem is that while you are verifying the build and someone pushes some code your commit ids will change on a rebase.
As for the revert the change was erroneous and had to be reverted. Though I am not very sure on why xapi versioning should include ³-SNAPSHOT², my guess is it is because we we make changes to standard xapi. Hopefully this will go away in future xapi releases. -abhi On 17/12/13 5:05 pm, "Daan Hoogland" <daan.hoogl...@gmail.com> wrote: >is it neccessary to work with a revert? How about creating a >(mini-)branch next time? This would obsolete my request for a tag on >the RC as it is in fact. UIt will also make it easier to implement >fixes that have to do with release instead of functionality. > >regards, > >On Mon, Dec 16, 2013 at 10:42 AM, Abhinandan Prateek ><abhinandan.prat...@citrix.com> wrote: >> >> >> On 14/12/13 11:49 pm, "Chip Childers" <chip.child...@gmail.com> wrote: >> >>>On Friday, December 13, 2013, Abhinandan Prateek wrote: >>> >>>> >>>> >>>> On 13/12/13 9:20 pm, "Chip Childers" >>>><chipchild...@apache.org<javascript:;>> >>>> wrote: >>>> >> >>>> >> > <artifactId>xapi</artifactId> >>>> >> > <version>5.6.100-1-SNAPSHOT</version> >>>> >> >>>> >> The specific project version ^^ >>>> >> >>>> >> For all previous releases, we have been releasing this specific >>>>pom.xml >>>> >> file with the appropriate *non SNAPSHOT* versions for both the >>>>parent >>>> >> version number and the XenServerJava project's version number >>>> >> (specifically setting the latter to 5.6.100-1). >>>> >> >>>> >> Since we are releasing the XenServerJava code as part of ACS, why >>>>would >>>> >> we leave the SNAPSHOT in there? >>>> >> >>>> >> Did something change that requires it to be added back? >>>> >> >>>> >> -chip >>>> > >>>> >I'll also point out that the reason that this is doing a mv then the >>>> >perl string changes is that there used to be a bug in the mvn >>>>versions >>>> >plugin that changed the XenServerJava version to the ACS version. >>>>This >>>> >appears to have been fixed (just tested). So actually, the mv can be >>>> >removed or not, it doesn't really matter because it's basically a >>>>noop. >>>> > >>>> >However -1 still stands unless someone convinces me that we should >>>> >release the XenServerJava project with -SNAPSHOT. IIRC, that >>>>actually >>>> >caused problems for us somehow (but I can't find a reference to that >>>>to >>>> >back up my sometimes fuzzy memory). >>>> > >>>> >>>> I was pointed to this ticket CLOUDSTACK-4827. The info is not very >>>>clear >>>> and it appears that this fixes probably a bad version for the repo, >>>>and >>>> not for the build. >>>> >>>> -abhi >> >> The commit is reverted. Will be re-spinning the 4.2.1 now. >> >>> >>
