[nvmewin] Versioning proposal for trunk/

[Freyensee, James P]

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/791a70be/attachment.html>