[Open-FCoE] fcoe-utils tagging

Joe Eykholt jeykholt at cisco.com
Thu Dec 17 18:39:16 UTC 2009

Love, Robert W wrote:
>> -----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
>> 2.6.32
>>> 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
>> package.
> 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
>> seems
>> 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.

Yes.  I figured the script would just keep its own version.

> 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,
>> then
>> something really changed in the tool itself, not just in the packaging
>> or
>> 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.

I realize.  It's just that if there is no difference then I would hope
the version wouldn't change.  Not a big deal, though, since there
will usually be at least minor changes.

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

That'd be nice, but maybe not necessary.


More information about the devel mailing list