[
https://issues.apache.org/jira/browse/BIGTOP-1580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14263909#comment-14263909
]
Olaf Flebbe commented on BIGTOP-1580:
-------------------------------------
Ok, let me explain it more carefully:
In Bigtop {{packages.gradle}} enforces this naming and versioning scheme
{code}
"name-${PKG_VERSION}${BIGTOP_BUILD_STAMP}-${RELEASE_VERSION}${RELEASE_DIST}....."
{code}
* PKG_NAME is the upstream package name (hive, spark, ...)
* PKG_VERSION the upstream version number (sometimes sanitized)
* RELEASE_VERSION is de facto 1
* RELEASE_DIST (only present in RPM builds) is do distinguish rhel6, rhel7,
opensuse etc.
This gives for instance
{code}
hive-0.14${BIGTOP_BUILD_STAMP}-1
{code}
It is policy in RPM and DEB build systems that every packaged version the
release version should be incremented in order to differentiate different
packaging attempts and to enable packaging upgrades.
https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version
http://www.rpm.org/max-rpm/ch-rpm-file-format.html
For instance a fix for packaging {{hive}} should result for instance in an
change of {{hive-0.14-1}} to {{hive-0.14-2}} , increasing the "release" part. A
new upstream version 0.15 should result in resetting the "release" part 1 to
{{hive-0.15-1}}
The {{$\{BIGTOP_BUILD_STAMP}}} cannot be used to mimic this behavior, because
it is placed in the upstream version part, not in the release part of the
version number. (The Release Part is not allowed to contain minus a dash "-")
Unfortunately nobody from the bigtop developers increases RELEASE_VERSION if
he/she/it fixes something. The -1 stays forever....
In the end the DEBIAN / YUM repositories populated with consecutive builds
from git the version are not suitable for automatic upgrades.
h2. I propose :
h3. Dropping the XXX_RELEASE
Rational:
* nobody uses it.
* If used like the policies intended, handling is clumsy. Since it has to be
increased it with every patch, it gives patch conflicts every time different
changes to the same packages are developed.
h3. Use Version scheme {{name-$\{PKG_VERSION}-$\{BIGTOP_BUILD_STAMP}}}
Rational:
* Puts an build stamp into the release part of the version, as policies suggest.
h3. Use grade to synthesize consecutive build stamp numbers for
{{$\{BIGTOP_BUILD_STAMP}}}
Rational:
* In order to get an automagically increased RELEASE part if a package is
rebuild, without messing with the upstream version. Enabling upgrades from repo
without additional quirks.
> Improve Bigtop Toolchain: Versioning of Packages
> ------------------------------------------------
>
> Key: BIGTOP-1580
> URL: https://issues.apache.org/jira/browse/BIGTOP-1580
> Project: Bigtop
> Issue Type: Bug
> Components: build, debian, rpm
> Affects Versions: 0.3.0
> Reporter: Olaf Flebbe
> Fix For: 0.9.0
>
>
> Right now there is no build numbering (beyond -1 ) for different packaging
> attempts and bigtop releases.
> There is no workable way to increase build numbering in Bigtop. (At least
> this is the situation for ubuntu and debian, have not checked RPM).
> This leads to indentical package versions and buildnumbers for different
> bigtop builds when no package version upgrade has been made. This is not
> desirable , since it essentially disables package upgrades at all.
> There is a BIGTOP_BUILD_STAMP which could be used to introduce the needed
> semantics but sadly this BIGTOP_BUILD_STAMP is appended to the PKG_VERSION
> part of the numbering, not the RELEASE_VERSION part .
> I vote to move BIGTOP_BUILD_STAMP to the "right" place in the
> package-version: Appending to RELEASE_VERSION
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
