[nvmewin] Versioning proposal for trunk/

[Alex Chang]

Hi all,

Since no more feedbacks/objections had been received, I would say the proposal from Jay and Kenny works fine with me. I will start to incorporate it when adding next patch into the base. Basically, there is no change to COMMNvme.DeviceDesc and driver version format is defined as: Major.Minor.NVMeSpecRevision.PatchNumber
When I push next patch, the driver version logged in nvme.inf will be 1.2.1014.21.
Thank you, Jay and Kenny, for the proposal.

Regards,
Alex

From: Freyensee, James P [mailto:james.p.freyensee at intel.com]
Sent: Thursday, January 30, 2014 12:39 PM
To: Speer, Kenny; Alex Chang; nvmewin at lists.openfabrics.org
Subject: RE: Versioning proposal for trunk/

I like this versioning idea :).

I think this along with adding the NVMe spec version in COMMNvme.DeviceDesc makes it very clear what code version someone is pulling from trunk/ and when trunk/ will reflect the next NVMe spec target.


From: Speer, Kenny [mailto:Kenny.Speer at netapp.com]
Sent: Thursday, January 30, 2014 12:32 PM
To: Alex Chang; Freyensee, James P; nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: RE: Versioning proposal for trunk/

It's clear that you not only want to track the NVMe spec that the current version implements, but also want to track driver specific changes (such as implementing new features).

A suggestion would be to continue using the Major.Minor to reflect driver versions and use the Release.Build fields to describe the spec and revision.  The Release field could contain a 4 digit number where the first two digits represent the Major Spec and the last 2 represent the revision.  For instance, in your example of 1.3.00 supporting up to 1.0e, the full version would be: 1.3.1014.36 where 10 = 1.0 and 14 = rev e and 36 = change number.  This way you could release a 1.4.1014.36 which contains only driver infrastructure changes (i.e. WPP tracing) without effecting the NVMe spec that it adheres to.

~kenny

From: Alex Chang [mailto:Alex.Chang at pmcs.com]
Sent: Thursday, January 30, 2014 12:22 PM
To: Freyensee, James P; Speer, Kenny; nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: RE: Versioning proposal for trunk/

I wouldn't be against reflecting NVMe specification version in the COMMNvme.DeviceDesc. However,  the up-coming release will be versioned as 1.3.0.0 supporting up to 1.0e. Please provide your thoughts if you have any.

Thanks,
Alex

From: Freyensee, James P [mailto:james.p.freyensee at intel.com]
Sent: Wednesday, January 29, 2014 6:49 PM
To: Alex Chang; Speer, Kenny; nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: RE: Versioning proposal for trunk/

So then why not have the NVMe standard target version in the COMMNvme.DeviceDesc and change this target version when trunk/ is focusing on the next NVMe standard?  Then when this happens the driver revision number goes from:

1.2.X.Y (NVMe 1.0.e version, reflected in COMMNvme.DeviceDesc) --> 1.3.0.0 (NVMe 1.1 version, reflected in COMMNvme.DeviceDesc)

??


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

Hi James,

Yes, the driver displays its name in Device Manager via COMMNvme.DeviceDesc.
As for the driver revision number in .inf file, the last release is 1.2.0.0 and we mean to keep the first two numbers as release numbers for the future to comply with Windows versioning. I am open to any proposals using the last two numbers.

Thanks,
Alex

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:25 PM
To: Speer, Kenny; nvmewin at lists.openfabrics.org<mailto:nvmewin at lists.openfabrics.org>
Subject: Re: [nvmewin] Versioning proposal for trunk/

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<mailto: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/20140204/55ba205a/attachment.html>