[ipxe-devel] [ipxe] Add ability to build an RPM (#17)

Schlomo Schapiro notifications at github.com
Mon Jun 30 10:45:30 UTC 2014

The Fedora docs do not require the version to follow the traditional x.y.z
scheme. They only require that newer packages will always upgrade older

Basically I suggest that instead of using a versioning scheme of x.y.z we
just use x and skip the y.z part.

And for x I suggest to use something that is guaranteed to always increase
with each change.

IMHO the traditional x.y.z numbering scheme has no meaning in a world where
every commit is production ready and covered with automatic tests that make
sure that only valid code will every get build into a package.

The only exception to that would be using x as an API version. In that case
iPXE should be versioned 1.<git rev-list count>.

However, as long as iPXE does not offer a public API IMHO there is no need
for that either.

On 30 June 2014 09:49, George Brown <notifications at github.com> wrote:

> For me it's more in line with how I would expect the version to appear in
> the RPM, similar to the Fedora description.
> http://fedoraproject.org/wiki/Packaging:NamingGuidelines#Package_Versioning
> Also whilst the 1.0.0 version number is unlikely to change soon, if it
> does in the future this version scheme would not reflect this. For example
> Ubuntu packages this with 1.0.0 followed by a commit for the version.
> apt-cache show ipxe | grep Version
> Version: 1.0.0+git-20131111.c3d1e78-2ubuntu1
> I agree the last commit/ number of commits should be reflected but that
> the major version should be the leading number.
>> Reply to this email directly or view it on GitHub
> <https://github.com/ipxe/ipxe/pull/17#issuecomment-47503434>.

Reply to this email directly or view it on GitHub:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ipxe.org/pipermail/ipxe-devel/attachments/20140630/9fbb3c4b/attachment.htm>

More information about the ipxe-devel mailing list