[
https://issues.apache.org/jira/browse/BIGTOP-1580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14291069#comment-14291069
]
Olaf Flebbe commented on BIGTOP-1580:
-------------------------------------
Management summary:
This patch enables a release workflow, but does not implement the workflow.
<too long>
Regarding your second suggestion: This versioning scheme is not upgradeable
since any "Beta" is old than any "Release", since comparing is left to right.
Test yourself for instance on centos with rpmdevtools
{code}
$ rpmdev-vercmp hive-0.14-1.bigtop0.9-99 hive-0.14-0.bigtop1.0-100
hive-0.14-1.bigtop0.9-99 > hive-0.14-0.bigtop1.0-100
{code}
Regarding your last (unnumbered) suggestion:
IMHO Placing a release number of the whole distro into the release is a good
thing as anyone does understand where a package comes from.
Regarding your first question:
Using the jenkins build number was only intended as a possible strictly
monotonic increasing token which can be inserted automatically. I am suggesting
not to hard code it to a Jenkins variable rather to be able to use it. If you
have to switch jenkins and want to be able to get increasing release numbers
beyond this change, you are free to add an offset to the jenkins build number.
Regarding the whole picture:
To be honest: The patch suggested is to get _my_ things done, quickly. It will
not fix the world.
Fixing the CI and Release process is more or less equivalent to chooseing a
proper text token to be inserted into the Release portion of the versioning
string.
I tried to introduce the least friction as possible by misusing an already
existing variable as a token to be inserted to the release.
Let me describe my workflow by example:
I did a full compile of Bigtop until it behaved somewhat reasonable, increasing
BIGTOP_BUILD_STAMP at each full recompile, getting hadoop-2.4.1-1, hive-0.14-1
.. hadoop-2.4.1-2, hive-0.14-2 ...
After l I decided to freeze and only to fix broken packages (for instance hive)
I only recompile hive getting version numbers like hadop-2.4.1-2 and
hive-0.14-3 .. hadop-2.4.1-2 and hive-0.14-4. After fixing all problems, I
brand these set of packages as a repository, shipping it without changing
anything.
So at each step the user/test can update installation with an apt-get upgrade
(And I presume it would work with yum update as well)
Next Release I will start with a full recompile with "5" .
Thats _my_ workflow, the bigtop workflow in Jenkins could be:
Doing a nightly full recompile on git master with
{code}
grade clean
BIGTOP_BUILD_STAMP="nightly-${BUILD_NUMBER}" grade apt / yum
{code}
Doing a release is a build from a git branch bigtop0.8 running every checking
{code}
grade clean
BIGTOP_BUILD_STAMP="bigtop0.8-${BUILD_NUMBER}" grade apt / yum
{code}
until stable.
If you like to test it yourself. the patch has to be updated, since there is a
problem with default numbering.
And yes: We should name BIGTOP_BUILD_STAMP differently.
> 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
> Assignee: Olaf Flebbe
> Fix For: 0.9.0
>
> Attachments: 0001-BIGTOP-1580-Change-Versioning-of-Packages.patch
>
>
> 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)
