I like this idea.
We should update the docs and describe how the release process works when there is a new file or an incompatible change in the flavor code.

Also, I am afraid, that we can easily forget to bump the flavor version, since it is not automatised. Maybe we can setup a rpkg macro for generating it, but it can be done later, if we really find that useful.

We should update the docs and describe how the release process works when there is a new file or an incompatible change in the flavor code.

Please tell where I should document this, I'd go for it.. The code is AFAIK only used by me (for internal copr purposes) so the motivation to document it is pretty low.

Also, I am afraid, that we can easily forget to bump the flavor version, since it is not automatised. Maybe we can setup a rpkg macro for generating it, but it can be done later, if we really find that useful.

Sounds like a good idea, more concrete hints are welcome.

We should update the docs and describe how the release process works when there is a new file or an incompatible change in the flavor code.

Please tell where I should document this, I'd go for it.. The code is AFAIK only used by me (for internal copr purposes) so the motivation to document it is pretty low.

I am not sure whether I understand it correctly then. I will give an example. In some PR I am renaming user_info.html file to user_meta.html file, i.e. doing an incompatible change for flavor package. I don't even know whether it is alright, but let's say that it gets +1 and gets merged. Then someone who is going to release a new version of copr-frontend, will have to increment this number

%global flavor_guard      %name-flavor = 2

correct? In that case, it probably should be mentioned here https://docs.pagure.org/copr.copr/how_to_release_copr.html#how-to-release-copr . Or, if there are some tests that will fail and tell us to bump the version, then I see no point in documenting it.

Alternatively, we can not bump the version in the release, but rather in PR that makes the change (which I don't like very much) or not care about it at all and wait until someone (you :wink:) reports, that we broke something. Either way, there needs to be a clear policy what to do and when.

I agree with frostyx that documentation of how to make the "theme" (flavor) package with explanation how it works together with the copr-frontend package would be useful. Even for us to understand it.

Agreed, I'll take a look at it.

Please take a look, I can describe any other particular detail (if needed).

Typo here, s/flovor/flavor/

I think that this is a good enough explanation of flavors. A Guide on how to create your own flavor would be nice, but it is not necessary since a very very very few people will need that.

The only thing that I am missing here is following. Let's imagine that I am a Copr maintainer and I am doing a release of copr-frontend. How can I be sure that no flavor file has been incompatibly changed during this release?

I would probably try something like

TAG=copr-frontend-1.132-1 ; comm -12 <(git diff --name-only $TAG master ./frontend/ |sed "s/^frontend\///" |sort) <(dnf -q repoquery -l copr-frontend-fedora |sed "s/^\/usr\/share\/copr\///"| sort)

which is incredibly ugly, but at least gives some idea of changed flavor files. If we could improve and automatize a check like that, it would be awesome. Or even improve and document.

On Saturday, June 16, 2018 4:39:47 PM CEST Jakub Kadl=C4=8D=C3=ADk wrote:

I think that this is a good enough explanation of flavors. A Guide on how=
to
create your own flavor would be nice, but it is not necessary since a very
very very few people will need that.

It is waiting for other copr deployments, and to have them there's a
lot of more important work to be done...

The only thing that I am missing here is following. Let's imagine that I =
am a
Copr maintainer and I am doing a release of copr-frontend.

I don't want to complicate things here, dunno. Previously you didn't like =
that,
but as with any other API maintenance - I'm pretty sure we should shift the
responsibility for bumping the version to the actual change
contributor/reviewewr; because it is not something which can be automatized.
Only the patch autor knows whether the change is incompatible or not :-(

How can I be sure that no flavor file has been incompatibly changed during
this release?

Agreed, it is a problem, and I'd claim this is not an algorithmic problem. =
I
don't really know how to proceed... ideally the '*-fedora' flavor would be
maintained separately, so we'd be able to see the problems asap.

(my motivation here is not to have rock solid versioning, but to make my li=
fe
easier so I dont have to rebuild the third party package all the time)

I'm pretty sure we should shift the
responsibility for bumping the version to the actual change
contributor/reviewewr

This is actually a very important statement. To this point, I wasn't sure who should be responsible for it. With that in mind, we don't need to complicate release process at all. :thumbsup: from me

I fixed the typo then, and dropped the "how_to_release_copr.rst" change.