Userspace versioning and releases

Userspace versioning and releases

[Joshua Brindle]

We have discussed a little lately about changing the way we do releases and versioning of the userspace components. One idea is to no longer version per-commit like we do now but instead only bump the version at release time.

This would be a problem for distros using Git as their upstream. One question is, who does this (I know Dan does) and what can we do to move you to using releases? First we want to do releases more often and time based (eg., every 2 or 3 months).

We also would like some way of relating versions of the components with each other, so that it is very easy to tell which libsepol you need for which checkpolicy and libselinux, for example. We'd also need to do this in a way that doesn't interfere with the current versions (no new version scheme should ever be seen as a downgrade to package managers, etc)

Are there any comments or suggestions on this? Does anyone completely object to this kind of change and why?

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Userspace versioning and releases

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Joshua Brindle wrote:
> We have discussed a little lately about changing the way we do releases and versioning of the userspace components. One idea is to no longer version per-commit like we do now but instead only bump the version at release time.
> 
> This would be a problem for distros using Git as their upstream. One question is, who does this (I know Dan does) and what can we do to move you to using releases? First we want to do releases more often and time based (eg., every 2 or 3 months).
> 
> We also would like some way of relating versions of the components with each other, so that it is very easy to tell which libsepol you need for which checkpolicy and libselinux, for example. We'd also need to do this in a way that doesn't interfere with the current versions (no new version scheme should ever be seen as a downgrade to package managers, etc)
> 
> Are there any comments or suggestions on this? Does anyone completely object to this kind of change and why?

My concern would be release early/release often.  You will loose the
ability for rawhide to check your changes.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkjIJYcACgkQrlYvE4MpobNfrgCfSlsB6SX6B1qlobVdJ0eAXHNS
fqgAnjxtYUeAXYJ3Uo08W0xXepaLXuJJ
=EcvM
-----END PGP SIGNATURE-----

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.