Re: oprofile-0.9.7-rc1

[Maynard J. <may...@us...>]

Robert Richter wrote:
> On 17.06.11 09:45:13, Maynard Johnson wrote:
>> Suravee Suthikulpanit wrote:
>>> URL:
>>> http://sourceforge.net/projects/oprofile/files/oprofile/oprofile-0.9.7-rc1/oprofile-0.9.7-rc1.tar.gz/download
>>
>> Suravee,
>> Thanks again for rolling out this release.  So far, the RC looks
>> good.  I've successfully tested it on POWER7/SLES 11 SP1,
>> POWER5/SLES10 SP3, and Intel Xeon/SLES 10 SP2.  I would appreciate
>> some testing from other community members on other platforms.
> 
> Maynard and Suravee,
> 
> the version string in configure.in is set to "0.9.7git". Also
> v0.9.7-rc1 is not tagged in the git repository. It is not quite clear,
> which commit id 0.9.7-rc1 refers to. I assume it is the latest HEAD:
> 
>  cf1a20c Correct typo for possible counters for UNHALTED_REFERENCE_CYCLES
> 
> It would be great to have this version string in the repository as
Robert,
Yes, it's true that configure.in in our git repo still says "0.9.7git".  The instructions in the releasechecklist file suggests that the release manager changes this to "<v.r.m>-rc<n>" in a local copy that will be used to create the RC tar file (to be uploaded to SourceForge).  Then once we decide the release is good enough to GA, the "<v.r.m>" is committed to configure.in and we then run 'git tag RELEASE_<v_r_m>'.  I wouldn't object to changing the instructions so that we commit the "<v.r.m>-rc<n>" change in configure.in and tag each RC.

-Maynard

> done in the Linux kernel. We would then have a single tagged commit
> which increments the version number to 0.9.7-rc1 or so.  As we now are
> working with git, we can adopt this workflow. Do you think if we could
> handle versioning that way, or are there reasons against this?
> 
> Thanks,
> 
> -Robert
>