version-release for different branches

["Germán A. Racca"]

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?

All the best,
Germán.

-- 
Germán A. Racca
Fedora Package Maintainer
https://fedoraproject.org/wiki/User:Skytux

[Jon Ciesla]

On Tue, Sep 11, 2012 at 10:03 AM, "Germán A. Racca"
<german.racca(a)gmail.com&gt; wrote:
>  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? 
In f18, you would git merge master.  In f17, git merge f18.  In f16,
git merge f17.  But jumping from 2 to 4 is fine, too.

-J

>  All the best,
>  Germán.
>
>  --
>  Germán A. Racca
>  Fedora Package Maintainer
>  https://fedoraproject.org/wiki/User:Skytux
>  --
>  packaging mailing list
>  packaging(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/packaging 


-- 
http://cecinestpasunefromage.wordpress.com/
------------------------------------------------
in your fear, seek only peace
in your fear, seek only love

-d. bowie

["Germán A. Racca"]

On 09/11/2012 12:13 PM, Jon Ciesla wrote:
>  On Tue, Sep 11, 2012 at 10:03 AM, "Germán A. Racca"
>  <german.racca(a)gmail.com&gt; wrote:
> > 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? 
Thanks Jon for your quick answer.

>  In f18, you would git merge master.  In f17, git merge f18.  In f16,
>  git merge f17.  But jumping from 2 to 4 is fine, too. 
This way of doing git merge from a previous branch to the actual one 
implies modifying the spec file in f18/master branches to change version 
from 3 to 4, and in f17/16 branches to change version from 2 to 3, right?

OTOH, if I choose to jump from 2 to 4 in f17/16 branches, I only need to 
edit spec file in master branch, bump the spec file to 4, and then only 
git merge master in the lower branches, right?

Germán.

>  -J
> > All the best,
> > Germán.
> >
> > --
> > Germán A. Racca
> > Fedora Package Maintainer
> > https://fedoraproject.org/wiki/User:Skytux
> > --
> > packaging mailing list
> > packaging(a)lists.fedoraproject.org
> > https://admin.fedoraproject.org/mailman/listinfo/packaging
>
>
>  

-- 
Germán A. Racca
Fedora Package Maintainer
https://fedoraproject.org/wiki/User:Skytux

[Jon Ciesla]

On Tue, Sep 11, 2012 at 10:32 AM, "Germán A. Racca"
<german.racca(a)gmail.com&gt; wrote:
>  On 09/11/2012 12:13 PM, Jon Ciesla wrote:
> >
> > On Tue, Sep 11, 2012 at 10:03 AM, "Germán A. Racca"
> > <german.racca(a)gmail.com&gt; wrote:
> >>
> >> 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?
>
>
>  Thanks Jon for your quick answer. 
NP.

> > In f18, you would git merge master.  In f17, git merge f18.  In
> f16,
> > git merge f17.  But jumping from 2 to 4 is fine, too.
>
>
>  This way of doing git merge from a previous branch to the actual one implies
>  modifying the spec file in f18/master branches to change version from 3 to
>  4, and in f17/16 branches to change version from 2 to 3, right? 
Yes.

>  OTOH, if I choose to jump from 2 to 4 in f17/16 branches, I only need
> to
>  edit spec file in master branch, bump the spec file to 4, and then only git
>  merge master in the lower branches, right? 
Yes.

-J

>  Germán.
>
> > -J
> >>
> >> All the best,
> >> Germán.
> >>
> >> --
> >> Germán A. Racca
> >> Fedora Package Maintainer
> >> https://fedoraproject.org/wiki/User:Skytux
> >> --
> >> packaging mailing list
> >> packaging(a)lists.fedoraproject.org
> >> https://admin.fedoraproject.org/mailman/listinfo/packaging
> >
> >
> >
> >
>
>
>  --
>  Germán A. Racca
>  Fedora Package Maintainer
>  https://fedoraproject.org/wiki/User:Skytux
>  --
>  packaging mailing list
>  packaging(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/packaging 


-- 
http://cecinestpasunefromage.wordpress.com/
------------------------------------------------
in your fear, seek only peace
in your fear, seek only love

-d. bowie

[Stanislav Ochotnicky]

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 Ochotnicky <sochotnicky(a)redhat.com&gt;
Software Engineer - Base Operating Systems Brno

PGP: 7B087241
Red Hat Inc.                               http://cz.redhat.com

["Germán A. Racca"]

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

[Tom Lane]

Stanislav Ochotnicky <sochotnicky(a)redhat.com&gt; 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

[Stanislav Ochotnicky]

Quoting Tom Lane (2012-09-11 19:27:08)
>  Stanislav Ochotnicky <sochotnicky(a)redhat.com&gt; 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(a)redhat.com&gt;
Software Engineer - Base Operating Systems Brno

PGP: 7B087241
Red Hat Inc.                               http://cz.redhat.com

[Matthew Miller]

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(a)mattdm.org&gt;
Senior Systems Architect -- SEAS Computing
Harvard School of Engineering & Applied Sciences