selinux-policy package versioning change

[Chris Murphy]

We do not expect any impact to end users neither to developers unless the exact version was used somewhere. If there are no objections, we will make the change in a week time.

Final freeze begins a week from today. Even though the change is
intended to be transparent, I wonder if it's better to make sure the
change happens before freeze rather than appearing in an update after
release with a different versioning scheme on released media (ISOs and
images, etc).

I mention it now because for whatever reason some things that were
stable already in the hours before beta freeze actually didn't make it
onto beta composes.


--
Chris Murphy
_______________________________________________
selinux mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to selinux-***@lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/***@lists.fedoraproject.org
Do not reply to spam on the list, r

[justina colmena ~biz]

I'm still a little bit confused about the SELinux targeted policy
"development" process versus the actual "roll-out," implementation, and
deployment not only to Fedora on the deskop, but to various distributions of
"CentOS" or commercial installations of Red Hat Enterprise Linux (RHEL) "in
the cloud" especially on OpenVZ or other shared-kernel virtualization
technologies as the case may be for businesses and end users who might
otherwise benefit from SELinux Mandatory Access Control policies built in to
the Linux kernel.

Hi,
We plan to change the versioning scheme of the selinux-policy packages.
Based on a request to using tags in selinux-policy github repo, we
discussed further actions and possible automation and decided to couple the
tags with the package version, together with making a change for better
comprehensibility.
So far, the package version changed with branching a new Fedora release off
rawhide (e. g. 3.14.6 to 3.14.7), and the release part of the NVR scheme
was used for updates (3.14.7-1). After the change, the version would
contain the Fedora branch number and the sequential number of the package
in the branch (34.1), and the release part would be used only for changes
in packaging (34.1-1). It would apply to Fedora 34 and newer.
In github repo, tags matching the Fedora package version would be used
(v34.1), pairing the latest commit in github with the latest commit in the
package (34.1-1).
We do not expect any impact to end users neither to developers unless the
exact version was used somewhere. If there are no objections, we will make
the change in a week time.
Cheers,

[Zdenek Pytela]

Post by justina colmena ~biz
I'm still a little bit confused about the SELinux targeted policy
"development" process versus the actual "roll-out," implementation, and
deployment not only to Fedora on the deskop, but to various distributions of
"CentOS" or commercial installations of Red Hat Enterprise Linux (RHEL) "in
the cloud" especially on OpenVZ or other shared-kernel virtualization
technologies as the case may be for businesses and end users who might
otherwise benefit from SELinux Mandatory Access Control policies built in to
the Linux kernel.

Most of the development happens in the rawhide github branch and selected
commits subsequently go to stable Fedora releases as well as to Centos
Stream and RHEL. There is no package difference between various Fedora
editions and spins for the same version.

Post by justina colmena ~biz

Hi,
We plan to change the versioning scheme of the selinux-policy packages.
Based on a request to using tags in selinux-policy github repo, we
discussed further actions and possible automation and decided to couple

the

tags with the package version, together with making a change for better
comprehensibility.
So far, the package version changed with branching a new Fedora release

off

rawhide (e. g. 3.14.6 to 3.14.7), and the release part of the NVR scheme
was used for updates (3.14.7-1). After the change, the version would
contain the Fedora branch number and the sequential number of the package
in the branch (34.1), and the release part would be used only for changes
in packaging (34.1-1). It would apply to Fedora 34 and newer.
In github repo, tags matching the Fedora package version would be used
(v34.1), pairing the latest commit in github with the latest commit in

the

package (34.1-1).
We do not expect any impact to end users neither to developers unless the
exact version was used somewhere. If there are no objections, we will

make

the change in a week time.
Cheers,

[Zdenek Pytela]

We do not expect any impact to end users neither to developers unless

the exact version was used somewhere. If there are no objections, we will
make the change in a week time.
Final freeze begins a week from today. Even though the change is
intended to be transparent, I wonder if it's better to make sure the
change happens before freeze rather than appearing in an update after
release with a different versioning scheme on released media (ISOs and
images, etc).
I mention it now because for whatever reason some things that were
stable already in the hours before beta freeze actually didn't make it
onto beta composes.

The freeze is on Tuesday, the plan is Monday, or after GA if it fails for
some reason.

--
Chris Murphy
_______________________________________________
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
https://pagure.io/fedora-infrastructure