[Open-FCoE] fcoe-utils tagging

Love, Robert W robert.w.love at intel.com
Thu Dec 17 17:38:52 UTC 2009

>-----Original Message-----
>From: Joe Eykholt [mailto:jeykholt at cisco.com]
>Sent: Wednesday, December 16, 2009 6:40 PM
>To: Love, Robert W
>Cc: devel at open-fcoe.org
>Subject: Re: [Open-FCoE] fcoe-utils tagging
>Love, Robert W wrote:
>> A few things are occurring right now that have made me think about the
>> fcoe-utils tagging. These things are that Lucy and Eric are making
>> changes to multiple user space tools and that I'd like to have a
>> tarball for the "Downloads" page that has up-to-date code.
>> Eric and Lucy's changes just made me think about whether each tool
>> should have its own version or if there should be a common version.
>> Looking at Open-iSCSI as a model it seems to make sense to have one
>> version that's shared by all of the tools. Chris has just published
>> a patch to accomplish this during our build process. With this patch
>> we can increment the fcoe-utils version in configure.ac and it will
>> be imported as each tool's version string. I think that every time
>> this is incremented we should add a tag to the repository reflecting
>> that new version (we've been doing that already).
>> As I said, I'd also like the 2.6.32 tarball to have current code. The
>> problem is that a few applications have been added that require
>> exported kernel header files (for passthrough) and these exported
>> header files will not be available until 2.6.33. This means that I
>> can't simply grab the tip and create a tarball.
>> What I intend to do is to commit Chris' patch quickly (i.e. tomorrow).
>> I don't think Chris' patch will be controversial, but if it is,
>> please speak up now. I'm then going to generate a patch that modifies
>> the Makefile to not build any tools dependent on the kernel header
>> files. I'll tag that patch v2.6.32 and generate the tarball. Then
>> I'll revert that patch so that the fcoe-utils tip builds the
>> passthrough applications against a >2.6.32 kernel.
>> The bottom line is that I'll be committing Chris' patch quickly and
>> that I'll be reverting some Makefile changes and then reverting that
>> patch immediately. I'll also add a few new tags to the repo. I
>> expect the resultant fcoe-utils repo to look like this-
>> v2.6.33 - 1.0.10 - <some change>       <--- in the future
>>                  - <some change>
>>                  - <some change>
>>                  - revert last patch   <--- tomorrow
>> v2.6.32 - 1.0.9  - Remove kernel header dependent apps from build
>>           1.0.8  - Chris' versioning patch
>>                  - Current tip (Eric's version patch)
>> Thanks, //Rob
>Maybe we can have versions on the individual tools and a version for the

The main thing I don't like is fcoeadm and fcoemon having different
versions. I checked the version strings on iscsid, iscsiadm and the
iscsi package on a SuSE system and they were all the same version.
It then seemed logical to have the repo tagged with that version
as well and to extend that version to the secondary tools.

I guess that I look at it as release versioning and not functional
versioning. Also, if everything shares a version then it's easy to
debug compatibility issues.

>One minor issue is the fcc script.  Editing the version in the script
>wrong if the script hasn't changed.   I suppose the package version
>could be
>put inside the fcc script as part of the build, but it's unnecessary as
>it stands alone and doesn't need support from the rest of the package.

Would you be happy if fcc just didn't share the global version? You can
update its version as you like.

BTW: Chris' patch only touches applications that were reporting
versions. At least one app, fcping I think, didn't print a version at
all. There may need to be a later effort to add version strings to some
of the smaller tools.

>It's also nice to be able to know that if the versions are different,
>something really changed in the tool itself, not just in the packaging
>in some unrelated tool.

That information will remain in the git repository. I'd tag the repo
with the version number as well as bump the configure.ac. So, if you
wanted to know the difference between 1.0.8 and 1.0.9 you could just
use git to determine the difference and look at the patches to see
what had changed.

In the future, we could even get the log of changes between x and y
versions when doing a build and generate a changelog.

More information about the devel mailing list