[nvmewin] Versioning proposal for trunk/

[Freyensee, James P]

Oh ok, I thought COMMNvmeChat.DeviceDesc was the name/driver-title that shows up when you look at the driver under "Device Manager" in the device tree, but if CommNvme.DeviceDesc does it, then that's fine by me :).

I think that is a good idea, to have the numeric version match what is in COMMNvmeChat.DeviceDesc/ CommNvme.DeviceDesc.


From: Speer, Kenny [mailto:Kenny.Speer at netapp.com]
Sent: Wednesday, January 29, 2014 6:18 PM
To: Freyensee, James P; nvmewin at lists.openfabrics.org
Subject: RE: Versioning proposal for trunk/

Yes, that makes more sense, in fact the last version I grabbed shows:

CommNvme.DeviceDesc = "Community NVME Storport Miniport"
;COMMNvmeChat.DeviceDesc = "Intel Chatham Prototype Hardware"

So it's already been updated to be more generic, just add the specific version you want.  I do also suggest having the numeric version match for clarity.

From: nvmewin-bounces at lists.openfabrics.org<mailto:nvmewin-bounces at lists.openfabrics.org> [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Freyensee, James P
Sent: Wednesday, January 29, 2014 6:02 PM
To: Speer, Kenny; nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: Re: [nvmewin] Versioning proposal for trunk/

May be sufficient but associating 'e' as a hex value and making it '14' would not be as intuitive to the non-nvme open-source developer/maintainer, which is a goal I would like to meet.

Maybe using:

COMMNvmeChat.DeviceDesc = "NVMe 1.0.e open-source driver, version 36"

Would be good instead?

The current value is:

COMMNvmeChat.DeviceDesc = "Intel Chatham Prototype Hardware"

which I would think the goals of this project is beyond Intel Chatham Prototypes now?


From: Speer, Kenny [mailto:Kenny.Speer at netapp.com]
Sent: Wednesday, January 29, 2014 5:47 PM
To: Freyensee, James P; nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: RE: Versioning proposal for trunk/

The only issue is that Windows driver versioning is of the format Major.Minor.Release.Build using numerics in decimal only.  I've never tried to just munge the .inf version directly and have it differ from the driver but I suspect VS2013 will flag it.

Perhaps just use 1.0.14.36 to represent 1.0.e.36 ...

From: nvmewin-bounces at lists.openfabrics.org<mailto:nvmewin-bounces at lists.openfabrics.org> [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Freyensee, James P
Sent: Wednesday, January 29, 2014 5:19 PM
To: nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: [nvmewin] Versioning proposal for trunk/

May I propose a versioning change with respect to nvme.inf file and trunk/?

When I pull code from trunk/, I always would like to know what code I am getting with respect to the NVMe spec standard, without having to ask people or ask the email list what the NVMe standard target is.  I would also like to be able to easily tell what version of a compiled Open-source NVMe driver is running on a Windows OS.

What I would like to propose is for the .inf file to maintain the versioning in the following manner:

If trunk/ is targeting the NVMe 1.0.e standard (which I assume it is), then 'DriverVer' in the .inf file is set in the following manner:

DriverVer=1/29/2014,1.0.e.36

where "1.0.e" is the NVMe standard being targeted, and '36' is the 36th time code in trunk/ has been changed for the NVMe standard target (1.0.e in this case).

Thus, when the open-source team is ready to target the NVMe 1.1 standard, the last version of the 1.0.e code in trunk/ will go to a 1.0.e branch, and in trunk/ the new value for "DriverVer" in nvme.inf would be:

DriverVer=1/29/2014,1.1.0

When a first revision of code is done in trunk/ with respect to the NVMe 1.1 standard, the DriverVer in the .inf file would be:

DriverVer=1/29/2014,1.1.1

And for a 2nd revision in trunk/ it would be:

DriverVer=1/29/2014,1.1.2

etc., etc.

I welcome alternative ideas if this is not doable or not simplistic enough where when someone pulls code down from trunk/ they do not recognize exactly what standard the code is targeting.  Regardless, I want the goal to be a simple solution such that a person not familiar with Windows NVMe open-source development and maintenance instantly recognize what NVMe spec standard their copy of the nvme source-code/compiled-driver is targeting.

Thanks!

Jay Freyensee



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20140130/846b072c/attachment.html>