On 09/11/2012 12:37 PM, Stanislav Ochotnicky wrote:

Quoting Germán A. Racca (2012-09-11 17:03:51)

Hi list,

I have the following situation. I have a package whose version-release
in f17/16 is 0.1.14-2, but in f18/master branches it is 0.1.14-3
(because of a f18 mass rebuild). Suppose I'm going to update the spec
file, so in f18/master branches the new version-release will be
0.1.14-4, and for f17/16 branches if I "git merge master", then the
release will jump from 2 to 4. Is this ok? Or should I keep working with
different releases for different branches and forget about "git merge
master" in lower branches?


git merge master is the best (IMO) approach here. It will mean you will
clearly have the same spec file in all supported releases (same git
hash since it will be fast-forward merge).

What some people don't like is that F16/17 git history will contain
mention of F18 mass rebuild, but that is (again IMO) a very minor
"issue".



Stanislav, I liked your answer, many thanks for clarifying my doubts!
It's going to be this way.


--
Germán A. Racca
Fedora Package Maintainer
https://fedoraproject.org/wiki/User:Skytux
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging

Stanislav Ochotnicky <sochotnicky@redhat.com> writes:
> What some people don't like is that F16/17 git history will contain
> mention of F18 mass rebuild, but that is (again IMO) a very minor
> "issue".

FWIW, I beg to differ. There is no problem at all if you skip over
release number 3 in some branch, but having a specfile changelog that
lies about what happened in that branch is a bad idea. It'll lead to
confusion later.

regards, tom lane
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging

Quoting Tom Lane (2012-09-11 19:27:08)
> Stanislav Ochotnicky <sochotnicky@redhat.com> writes:
> > What some people don't like is that F16/17 git history will contain
> > mention of F18 mass rebuild, but that is (again IMO) a very minor
> > "issue".
>
> FWIW, I beg to differ. There is no problem at all if you skip over
> release number 3 in some branch, but having a specfile changelog that
> lies about what happened in that branch is a bad idea. It'll lead to
> confusion later.

If the commit was anything else than raising release tag and adding a
changelog entry I'd completely agree. As originally stated, I am aware
of opinions like yours and even if I don't agree...it's up to maintainer
to decide in the end (unless one of us brings the issue in front of
FPC/FESCO :-) ).

--
Stanislav Ochotnicky <sochotnicky@redhat.com>
Software Engineer - Base Operating Systems Brno

PGP: 7B087241
Red Hat Inc. http://cz.redhat.com
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging

On Wed, Sep 12, 2012 at 10:51:32AM +0200, Stanislav Ochotnicky wrote:
> > FWIW, I beg to differ. There is no problem at all if you skip over
> > release number 3 in some branch, but having a specfile changelog that
> > lies about what happened in that branch is a bad idea. It'll lead to
> > confusion later.
> If the commit was anything else than raising release tag and adding a
> changelog entry I'd completely agree. As originally stated, I am aware
> of opinions like yours and even if I don't agree...it's up to maintainer
> to decide in the end (unless one of us brings the issue in front of
> FPC/FESCO :-) ).

+1. In this case, the changelog entry simply serves to explain what happened
to the missing number -- there was a build with no changes made. If it
described changes, that'd be a different issue. (It happens that that
particular build didn't really happen on this branch, but from the POV of
what a rpm changelog is useful for, that's irrelevant.

--
Matthew Miller <mattdm@mattdm.org>
Senior Systems Architect -- SEAS Computing
Harvard School of Engineering & Applied Sciences
--
packaging mailing list
packaging@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging