Re: [Fedora-packaging] Re: (fix typos) Re: Packaging:NamingGuidelines Re: DNF is completly unable to act with local packages

[Sérgio Basto]

Hi, 

On Seg, 2015-11-30 at 12:15 +0100, Dominik 'Rathann' Mierzejewski
wrote:
> On Tuesday, 24 November 2015 at 14:56, Sérgio Basto wrote:
> > Switching to packag...@lists.fedoraproject.org 
> [...]
> > In this link http://fedoraproject.org/wiki/Packaging:NamingGuidelin
> > es#Pre-Release_packages ;
> > where we read :
> > 
> > Release Tag for Pre-Release Packages: 
> > 
> > 0.%{X}.%{alphatag}%{?dist}   
> > 
> > And I'm proposing : 
> > 
> > 0[.%{X}].%{alphatag}[.%{Y}]%{?dist} 
> > 
> > is just better IMHO .
> 
> Personally, I think it's too complicated due to the optional nature
> of X and Y parts and it's just as easy to get wrong if subsequent
> alphatag breaks release monontonicity and the package maintainer
> doesn't notice it.
> 
> With X being currently mandatory, at least you know you must always
> increase it every time you update the package, so monotonicity is
> preserved.

Other argument that I forgot to mention is: this is an extension of
first version so nobody needs change his package naming and is an
extension in two ways :
1 - Possibility of begin with 0 , before was need be: 0.%{X} 
2 - Possibility of write in right . 

The current: 0.%{X}.%{alphatag}%{?dist}
Extension 1: 0[.%{X}].%{alphatag}%{?dist}
Extension 2: 0[.%{X}].%{alphatag}[.%{Y}]%{?dist}

I'd like to have permission to use in some of "my" packages.

> Regards,
> Dominik
-- 
Sérgio M. B.

--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: [Fedora-packaging] Re: (fix typos) Re: Packaging:NamingGuidelines Re: DNF is completly unable to act with local packages

[Dominik 'Rathann' Mierzejewski]

On Tuesday, 24 November 2015 at 14:56, Sérgio Basto wrote:
> Switching to packag...@lists.fedoraproject.org 
[...]
> In this link 
> http://fedoraproject.org/wiki/Packaging:NamingGuidelines#Pre-Release_packages 
> where we read :
> 
> Release Tag for Pre-Release Packages: 
> 
> 0.%{X}.%{alphatag}%{?dist}   
> 
> And I'm proposing : 
> 
> 0[.%{X}].%{alphatag}[.%{Y}]%{?dist} 
> 
> is just better IMHO .

Personally, I think it's too complicated due to the optional nature
of X and Y parts and it's just as easy to get wrong if subsequent
alphatag breaks release monontonicity and the package maintainer
doesn't notice it.

With X being currently mandatory, at least you know you must always
increase it every time you update the package, so monotonicity is
preserved.

Regards,
Dominik
-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: (fix typos) Re: Packaging:NamingGuidelines Re: DNF is completly unable to act with local packages

[Sérgio Basto]

On Ter, 2015-11-24 at 08:18 -0500, Jared K. Smith wrote:
> 
> On Mon, Nov 23, 2015 at 8:47 PM, Sérgio Basto 
> wrote:
> > we have two counters, one when upstream change the source
> > other when we rebuild the package, it will be better readable, to
> > understand if the upstream had updates or not.
> > 
> 
> Maybe I'm not understanding you well, but we *do* have two
> counters... in fact, we have *three*.  We have epoch, version, and
> release.  When an upstream community puts out a newer version of the
> software, the version number should increase.  When the packager puts
> out a new package with the same version number, she/he should
> increase the release number.  This is why pre-release software should
> have a release number that begins with "0.", so that when the
> production release happens, the release number can start at "1". 
> Last but not least, Epoch can be used to override the version and
> release numbers in special cases where the version and release
> numbers of a newer release don't sort to the top.  (One such example
> might be if we needed to downgrade a particular package for some
> reason.)
> 
> Does that help make things more clear?

Use epoch is one solution but in my mind, epoch is for breakage, we
should avoid use epoch, epoch was needed to install kde4 over F23 :) 
Thanks,
-- 
Sérgio M. B.


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: (fix typos) Re: Packaging:NamingGuidelines Re: DNF is completly unable to act with local packages

[Jared K. Smith]

On Mon, Nov 23, 2015 at 8:47 PM, Sérgio Basto  wrote:

> we have two counters, one when upstream change the source
> other when we rebuild the package, it will be better readable, to
> understand if the upstream had updates or not.
>


Maybe I'm not understanding you well, but we *do* have two counters... in
fact, we have *three*.  We have epoch, version, and release.  When an
upstream community puts out a newer version of the software, the version
number should increase.  When the packager puts out a new package with the
same version number, she/he should increase the release number.  This is
why pre-release software should have a release number that begins with
"0.", so that when the production release happens, the release number can
start at "1".  Last but not least, Epoch can be used to override the
version and release numbers in special cases where the version and release
numbers of a newer release don't sort to the top.  (One such example might
be if we needed to downgrade a particular package for some reason.)

Does that help make things more clear?

--
Jared Smith
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: (fix typos) Re: Packaging:NamingGuidelines Re: DNF is completly unable to act with local packages

[Sérgio Basto]

Switching to packag...@lists.fedoraproject.org 

On Ter, 2015-11-24 at 01:47 +, Sérgio Basto wrote:
> On Seg, 2015-11-23 at 09:39 +0100, Dominik 'Rathann' Mierzejewski
> wrote:
> > On Sunday, 22 November 2015 at 00:46, Sérgio Basto wrote:
> > > On Sex, 2015-11-20 at 15:18 +0100, Tomas Mraz wrote:
> > > > On Čt, 2015-11-19 at 20:59 +, Sérgio Basto wrote:
> > > > > On Qua, 2015-11-18 at 17:11 -0600, Jason L Tibbitts III
> > > > > wrote:
> > > > > > > > > > > "SB" == Sérgio Basto  writes:
> > > > > > 
> > > > > > SB> When we fix the .spec and don't change the source, we
> > > > > > bump
> > > > > > rightmost
> > > > > > SB> version, when we change the source, we bump the left
> > > > > > version,
> > > > > > so
> > > > > > we
> > > > > > SB> can distinguish when we update the source and when we
> > > > > > updated
> > > > > > the
> > > > > > SB> .spec, this contrast for me is important.
> > > > > > 
> > > > > > For me, the simple rule that a Release: tag less than 1
> > > > > > implies
> > > > > > prerelease software, while a Release: tag of 1 or greater
> > > > > > implies
> > > > > > a
> > > > > > post-release package, is important.  So far the proponents
> > > > > > of
> > > > > > this
> > > > > > change haven't shown what things would actually look like
> > > > > > after
> > > > > > this
> > > > > > change, so it's hard for me to come up with a reason to
> > > > > > change my
> > > > > > opinion.
> > > > > 
> > > > > prerelease numbering can't begin with 0 and increased to 0.1
> > > > > because :
> > > > > 
> > > > > next version of foo-0.b would be foo-0.1.b and "b">1 
> > > > 
> > > > Nope, 1>"b" in rpm version compare.
> > 
> > Even so, we shouldn't depend on upstream preserving sorting order
> > in
> > their pre-release suffixes. Numerical sorting is always monotonous.
> > 
> > > If so, we could begging numeration with 0 for pre-release: 
> > > 
> > > foo-0.c -> foo-0.c.1 -> foo-0.1.b -> foo-0.1.b.1 -> foo-0.2.a ->
> > > foo-
> > > 0.2.a.1 
> > 
> > I don't understand why you want to introduce another level of
> > numbering.
> > What's wrong with the current guideline?
> 
> I'd like improve for cases that upstream doesn't make a release and
> the package stays forever in a pre-release, this happens a lot with
> old projects that are half dead upstream, instead of have just one
> counter, we have two counters, one when upstream change the source
> other when we rebuild the package, it will be better readable, to
> understand if the upstream had updates or not.


In this link 
http://fedoraproject.org/wiki/Packaging:NamingGuidelines#Pre-Release_packages 
where we read :

Release Tag for Pre-Release Packages: 

0.%{X}.%{alphatag}%{?dist}   

And I'm proposing : 

0[.%{X}].%{alphatag}[.%{Y}]%{?dist} 

is just better IMHO .


> Best regards,
> -- 
> Sérgio M. B.
> 
> 
-- 
Sérgio M. B.


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Packaging:NamingGuidelines Re: DNF is completly unable to act with local packages

[Dominik 'Rathann' Mierzejewski]

On Sunday, 22 November 2015 at 00:46, Sérgio Basto wrote:
> On Sex, 2015-11-20 at 15:18 +0100, Tomas Mraz wrote:
> > On Čt, 2015-11-19 at 20:59 +, Sérgio Basto wrote:
> > > On Qua, 2015-11-18 at 17:11 -0600, Jason L Tibbitts III wrote:
> > > > > > > > > "SB" == Sérgio Basto  writes:
> > > > 
> > > > SB> When we fix the .spec and don't change the source, we bump
> > > > rightmost
> > > > SB> version, when we change the source, we bump the left version,
> > > > so
> > > > we
> > > > SB> can distinguish when we update the source and when we updated
> > > > the
> > > > SB> .spec, this contrast for me is important.
> > > > 
> > > > For me, the simple rule that a Release: tag less than 1 implies
> > > > prerelease software, while a Release: tag of 1 or greater implies
> > > > a
> > > > post-release package, is important.  So far the proponents of
> > > > this
> > > > change haven't shown what things would actually look like after
> > > > this
> > > > change, so it's hard for me to come up with a reason to change my
> > > > opinion.
> > > 
> > > prerelease numbering can't begin with 0 and increased to 0.1
> > > because :
> > > 
> > > next version of foo-0.b would be foo-0.1.b and "b">1 
> > 
> > Nope, 1>"b" in rpm version compare.

Even so, we shouldn't depend on upstream preserving sorting order in
their pre-release suffixes. Numerical sorting is always monotonous.

> If so, we could begging numeration with 0 for pre-release: 
> 
> foo-0.c -> foo-0.c.1 -> foo-0.1.b -> foo-0.1.b.1 -> foo-0.2.a -> foo-
> 0.2.a.1 

I don't understand why you want to introduce another level of numbering.
What's wrong with the current guideline?

Regards,
Dominik
-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Packaging:NamingGuidelines Re: DNF is completly unable to act with local packages

[Sérgio Basto]

On Seg, 2015-11-23 at 09:39 +0100, Dominik 'Rathann' Mierzejewski
wrote:
> On Sunday, 22 November 2015 at 00:46, Sérgio Basto wrote:
> > On Sex, 2015-11-20 at 15:18 +0100, Tomas Mraz wrote:
> > > On Čt, 2015-11-19 at 20:59 +, Sérgio Basto wrote:
> > > > On Qua, 2015-11-18 at 17:11 -0600, Jason L Tibbitts III wrote:
> > > > > > > > > > "SB" == Sérgio Basto  writes:
> > > > > 
> > > > > SB> When we fix the .spec and don't change the source, we
> > > > > bump
> > > > > rightmost
> > > > > SB> version, when we change the source, we bump the left
> > > > > version,
> > > > > so
> > > > > we
> > > > > SB> can distinguish when we update the source and when we
> > > > > updated
> > > > > the
> > > > > SB> .spec, this contrast for me is important.
> > > > > 
> > > > > For me, the simple rule that a Release: tag less than 1
> > > > > implies
> > > > > prerelease software, while a Release: tag of 1 or greater
> > > > > implies
> > > > > a
> > > > > post-release package, is important.  So far the proponents of
> > > > > this
> > > > > change haven't shown what things would actually look like
> > > > > after
> > > > > this
> > > > > change, so it's hard for me to come up with a reason to
> > > > > change my
> > > > > opinion.
> > > > 
> > > > prerelease numbering can't begin with 0 and increased to 0.1
> > > > because :
> > > > 
> > > > next version of foo-0.b would be foo-0.1.b and "b">1 
> > > 
> > > Nope, 1>"b" in rpm version compare.
> 
> Even so, we shouldn't depend on upstream preserving sorting order in
> their pre-release suffixes. Numerical sorting is always monotonous.
> 
> > If so, we could begging numeration with 0 for pre-release: 
> > 
> > foo-0.c -> foo-0.c.1 -> foo-0.1.b -> foo-0.1.b.1 -> foo-0.2.a ->
> > foo-
> > 0.2.a.1 
> 
> I don't understand why you want to introduce another level of
> numbering.
> What's wrong with the current guideline?

I'd like improve for cases that upstream doesn't not make a release and
the package that stay forever in a pre-release, this happens a lot with
old projects that are half dead upstream, instead of have just one
counter, we have two counter, one when upstream change other when we
bump a release, will be better readable , for understanding if upstream
source change or not . 


-- 
Sérgio M. B.


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

(fix typos) Re: Packaging:NamingGuidelines Re: DNF is completly unable to act with local packages

[Sérgio Basto]

On Seg, 2015-11-23 at 09:39 +0100, Dominik 'Rathann' Mierzejewski
wrote:
> On Sunday, 22 November 2015 at 00:46, Sérgio Basto wrote:
> > On Sex, 2015-11-20 at 15:18 +0100, Tomas Mraz wrote:
> > > On Čt, 2015-11-19 at 20:59 +, Sérgio Basto wrote:
> > > > On Qua, 2015-11-18 at 17:11 -0600, Jason L Tibbitts III wrote:
> > > > > > > > > > "SB" == Sérgio Basto  writes:
> > > > > 
> > > > > SB> When we fix the .spec and don't change the source, we
> > > > > bump
> > > > > rightmost
> > > > > SB> version, when we change the source, we bump the left
> > > > > version,
> > > > > so
> > > > > we
> > > > > SB> can distinguish when we update the source and when we
> > > > > updated
> > > > > the
> > > > > SB> .spec, this contrast for me is important.
> > > > > 
> > > > > For me, the simple rule that a Release: tag less than 1
> > > > > implies
> > > > > prerelease software, while a Release: tag of 1 or greater
> > > > > implies
> > > > > a
> > > > > post-release package, is important.  So far the proponents of
> > > > > this
> > > > > change haven't shown what things would actually look like
> > > > > after
> > > > > this
> > > > > change, so it's hard for me to come up with a reason to
> > > > > change my
> > > > > opinion.
> > > > 
> > > > prerelease numbering can't begin with 0 and increased to 0.1
> > > > because :
> > > > 
> > > > next version of foo-0.b would be foo-0.1.b and "b">1 
> > > 
> > > Nope, 1>"b" in rpm version compare.
> 
> Even so, we shouldn't depend on upstream preserving sorting order in
> their pre-release suffixes. Numerical sorting is always monotonous.
> 
> > If so, we could begging numeration with 0 for pre-release: 
> > 
> > foo-0.c -> foo-0.c.1 -> foo-0.1.b -> foo-0.1.b.1 -> foo-0.2.a ->
> > foo-
> > 0.2.a.1 
> 
> I don't understand why you want to introduce another level of
> numbering.
> What's wrong with the current guideline?

I'd like improve for cases that upstream doesn't make a release and
the package stays forever in a pre-release, this happens a lot with
old projects that are half dead upstream, instead of have just one
counter, we have two counters, one when upstream change the source
other when we rebuild the package, it will be better readable, to
understand if the upstream had updates or not.

Best regards,
-- 
Sérgio M. B.


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Packaging:NamingGuidelines Re: DNF is completly unable to act with local packages

[Sérgio Basto]

On Sex, 2015-11-20 at 15:18 +0100, Tomas Mraz wrote:
> On Čt, 2015-11-19 at 20:59 +, Sérgio Basto wrote:
> > On Qua, 2015-11-18 at 17:11 -0600, Jason L Tibbitts III wrote:
> > > > > > > > "SB" == Sérgio Basto  writes:
> > > 
> > > SB> When we fix the .spec and don't change the source, we bump
> > > rightmost
> > > SB> version, when we change the source, we bump the left version,
> > > so
> > > we
> > > SB> can distinguish when we update the source and when we updated
> > > the
> > > SB> .spec, this contrast for me is important.
> > > 
> > > For me, the simple rule that a Release: tag less than 1 implies
> > > prerelease software, while a Release: tag of 1 or greater implies
> > > a
> > > post-release package, is important.  So far the proponents of
> > > this
> > > change haven't shown what things would actually look like after
> > > this
> > > change, so it's hard for me to come up with a reason to change my
> > > opinion.
> > 
> > prerelease numbering can't begin with 0 and increased to 0.1
> > because :
> > 
> > next version of foo-0.b would be foo-0.1.b and "b">1 
> 
> Nope, 1>"b" in rpm version compare.

If so, we could begging numeration with 0 for pre-release: 

foo-0.c -> foo-0.c.1 -> foo-0.1.b -> foo-0.1.b.1 -> foo-0.2.a -> foo-
0.2.a.1 

I will write to Fedora-packaging mailing list, proposing changing
Packaging:NamingGuidelines -> Package versioning -> Pre-Release, where
we may or should use the left and the right numeration ... 

Thanks, 

> -- 
> Tomas Mraz
> No matter how far down the wrong road you've gone, turn back.
>   Turkish proverb
> (You'll never know whether the road is wrong though.)
> 
> 
-- 
Sérgio M. B.


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Packaging:NamingGuidelines Re: DNF is completly unable to act with local packages

[Tomas Mraz]

On Čt, 2015-11-19 at 20:59 +, Sérgio Basto wrote:
> On Qua, 2015-11-18 at 17:11 -0600, Jason L Tibbitts III wrote:
> > > > > > > "SB" == Sérgio Basto  writes:
> > 
> > SB> When we fix the .spec and don't change the source, we bump
> > rightmost
> > SB> version, when we change the source, we bump the left version, so
> > we
> > SB> can distinguish when we update the source and when we updated the
> > SB> .spec, this contrast for me is important.
> > 
> > For me, the simple rule that a Release: tag less than 1 implies
> > prerelease software, while a Release: tag of 1 or greater implies a
> > post-release package, is important.  So far the proponents of this
> > change haven't shown what things would actually look like after this
> > change, so it's hard for me to come up with a reason to change my
> > opinion.
> 
> prerelease numbering can't begin with 0 and increased to 0.1 because :
> 
> next version of foo-0.b would be foo-0.1.b and "b">1 

Nope, 1>"b" in rpm version compare.

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
(You'll never know whether the road is wrong though.)


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Packaging:NamingGuidelines Re: DNF is completly unable to act with local packages

[Sérgio Basto]

On Qua, 2015-11-18 at 17:11 -0600, Jason L Tibbitts III wrote:
> > > > > > "SB" == Sérgio Basto  writes:
> 
> SB> When we fix the .spec and don't change the source, we bump
> rightmost
> SB> version, when we change the source, we bump the left version, so
> we
> SB> can distinguish when we update the source and when we updated the
> SB> .spec, this contrast for me is important.
> 
> For me, the simple rule that a Release: tag less than 1 implies
> prerelease software, while a Release: tag of 1 or greater implies a
> post-release package, is important.  So far the proponents of this
> change haven't shown what things would actually look like after this
> change, so it's hard for me to come up with a reason to change my
> opinion.

prerelease numbering can't begin with 0 and increased to 0.1 because :

next version of foo-0.b would be foo-0.1.b and "b">1 

so maybe next version of foo-0.b could be foo-0.b.1 

but if b change to a, you have to bump left side foo-1.a and can't bump
to 1 because is not final release. 

so the solution for all cases is: 

foo-0.1.b -> foo-0.1.b.1 -> foo-0.2.a -> foo-0.2.a.1 



>  - J<
-- 
Sérgio M. B.


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Packaging:NamingGuidelines Re: DNF is completly unable to act with local packages

[Jason L Tibbitts III]

> "SB" == Sérgio Basto  writes:

SB> When we fix the .spec and don't change the source, we bump rightmost
SB> version, when we change the source, we bump the left version, so we
SB> can distinguish when we update the source and when we updated the
SB> .spec, this contrast for me is important.

For me, the simple rule that a Release: tag less than 1 implies
prerelease software, while a Release: tag of 1 or greater implies a
post-release package, is important.  So far the proponents of this
change haven't shown what things would actually look like after this
change, so it's hard for me to come up with a reason to change my
opinion.

 - J<
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Packaging:NamingGuidelines Re: DNF is completly unable to act with local packages

[Sérgio Basto]

On Sáb, 2015-11-07 at 17:07 +0100, Michael Schwendt wrote:
> On Sat, 7 Nov 2015 17:18:14 +0200, Panu Matilainen wrote:
> 
> > Frankly I didn't even realize the 0.rc1.X scheme was against the 
> > guidelines since to me this is the (obviously) correct way to do it
> > with 
> > predictable pre-release names (its predictable when you're the one
> > doing 
> > the upstream tarballs), where the versioning goes like this:
> > 
> > 0.beta1.1
> > 0.beta1.2
> > 0.beta1.3
> > 0.beta2.1
> > 0.beta2.2
> > 0.rc1.1
> > 0.rc1.2
> > [...]
> > 0.rc1.5
> > 0.rc2.1
> > 1 (for the final)
> 
> And if you wanted to package a git snapshot somewhere on the middle
> of
> that road, you would need to be creative (and e.g. avoid going from
> "rc1"
> to "git").
> 
> No doubt -- there are versioning schemes where the alpha/beta/rc tags
> can even be part of %{version}, especially if upstream is aware of
> the
> pitfalls related to RPM version comparison. That has been a topic in
> the review queue just recently.
> 
> The guidelines aren't bullet-proof either. It's just that incidents
> like
> this raise my concerns with regard to this growing maze of packaging
> guidelines and the package review process.

I think the current numbering can be improved and 0.rc1.X doesn't look
bad to me , I agree should be 0.1.rc1.x but since rc is last state
before a release, the version 0.rc looks (even) better than 0.1.rc .

Anyway what I like in this approach is distinguish when we change
source and when bump the .spec, reading the guidelines [1] the example
of kismet pre-release svn checkout should use left and right versioning
:
 
kismet-0-0.1.20040110svn%{?dist}  
kismet-0-0.1.20040110svn.1%{?dist}
kismet-0-0.2.20040204svn%{?dist}

When we fix the .spec and don't change the source, we bump rightmost
version, when we change the source, we bump the left version, so we can
distinguish when we update the source and when we updated the .spec,
this contrast for me is important.  

[1] https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Pre-Relea
se_packages

Best regards,
-- 
Sérgio M. B.


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct