fedpkg build version numbering discrepancy

[Michael Schwendt]

On Thu, 27 Jan 2011 18:10:31 -0500, Jean-Marc wrote:

> Hello,
> 
> 	Hoping to be wrong.
> 
> 	Today I was working on my package after a long time,
> 	I upgraded from version 2.1-320 to 2.1-400.
> 
> 	I didn't "fedpkg new-sources" and only updated
> 	the spec file to be 2.1-400 (sources file was
> 	still referring to 2.1-320).
> 	fedpkg commit ; fedpkg push
> 
> 	Next, fedpkg build
> 
> 	Koji reported me 2.1-400 was compiled no trouble.
> 	how come? new tar file was not event uploaded...
> 
> 	Is my understanding right?, koji build
> 	report "spec file" version while crunching
> 	"sources file" version!
> 	Did I missed something or we are in "easy mistake"
> 	situation??.

I'm aware this has been solved in the rest of this thread already,
so just a comment on what else has happened to some packagers before:

They didn't use %{version} in the "Source" tag URL and used a %setup with
options to specify a custom version-less builddir. So. the source tarball
from the "sources" file had a different version than %version and no
version in its root directory name. As why this hadn't been an obvious
mistake? %version and %release consisted of an overly complex 
concatenation of several macro-fied numbers related to the upstream
versioning scheme, which made the spec less readable.

>	rversion=2.1
>	subversion=400
>
>
>	Spec file extract:
>	Version: %{rversion}.%{subversion}
>
>	Source: ...../%{name}-%{version}.tar.gz

IMO, it would be more clear to separate strictly between upstream version
(= tarball version) and Fedora package version. Apparently, both are the
same in your case, so why reconstruct them? Once you've started a particular
versioning scheme, you don't win a lot of flexibility by hiding the real
version in variables. You only increase the risk that an improper version
bump breaks the upgrade path, i.e. one cannot mess with %subversion anyway
and must increment it correctly in the context of the full %version. The
full %version is also absolutely important with regard to versioned
dependencies, Obsoletes and Provides. It would be fine to just use

  Version: 2.1.400

and if the 2.1 prefix is really needed elsewhere in the spec file and
perhaps has a meaning other than being just a number, assign it to a
separate variable.