[
https://issues.apache.org/jira/browse/BIGTOP-1580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14289749#comment-14289749
]
Mark Grover commented on BIGTOP-1580:
-------------------------------------
Apologies for the delayed response. Good idea, Olaf.
To ensure we have the same vocabulary, I have
name-version-release which seems to be in line with yours well.
I have a few questions and would appreciate if you could help answer them.
1. If we simply use the BIGTOP_BUILD_STAMP variable to populate, what happens
if we migrate our Jenkins server or clean out the job and the build numbers get
reset? I'd like to think it would be good to have a stop gap field in the
package's release identifier that we have complete control over in case the
build stamp gets reset.
2. Also, since we never release packages out of band of a bigtop release. Is it
worth considering putting bigtop version in the release identifier? In fact, I
would also vouch to keep RELEASE_VERSION which is almost always set to 1 before
the bigtop version.
That allows for us to things like a beta (for say, Bigtop 1.0) in which we may
call it Bigtop 1.0 but with RELEASE_VERSION as '0' (which is how most packages
would do it as).
So, in my ideal scheme, hive, for example would look something like
hive-0.14.1-1.bigtop0.9.158
hive: name
0.14.1: upstream version number
1: RELEASE_VERSION
bigtop0.9: bigtop release
158: Build Stamp
What do you think?
> 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)
