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.