[jira] [Commented] (BIGTOP-1580) Improve Bigtop Toolchain: Versioning of Packages

["Olaf Flebbe (JIRA)" <ji...@apache.org>]

    [ 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)