Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Include full version number in released file names #14612

Merged
merged 3 commits into from Nov 23, 2018

Conversation

Projects
None yet
7 participants
@achow101
Copy link
Member

commented Oct 30, 2018

As noted on IRC, the filenames of the gitian build results do not contain the 4th digit of the version number if it has one, e.g. 0.17.0.1 produces files with the number 0.17.0. Furthermore, when RC's are built, the resulting filenames are of the release version and do not include rc in them. This occurs because configure.ac is written to create version numbers of the form major.minor.rev instead of major.minor.rev.build and without any rc version as it does not handle rc numbers.

This PR changes configure.ac to include the build number if it is greater than 0. It will also include the rc number if it is greater than 0. So the filenames of the gitian builds will now contain the full version number.

This behavior can be tested by setting _CLIENT_VERSION_BUILD and _CLIENT_VERSION_RC to non-zero values and then doing make dist. A tar file should be created with the correct versioning.

achow101 added some commits Oct 30, 2018

build: if VERSION_BUILD is non-zero, include it in the package version
When the build number (CLIENT_VERSION_BUILD) is non-zero, we want
to include that in the package version number so the resulting binaries
are named with the correct version.
@luke-jr

This comment has been minimized.

Copy link
Member

commented Oct 30, 2018

So it would show 0.17.0.1rc1 if that was the version?

Might be nice to actually use the full version number generated from the tag, so non-tag builds get the commit hash in there...

@achow101

This comment has been minimized.

Copy link
Member Author

commented Oct 31, 2018

So it would show 0.17.0.1rc1 if that was the version?

It would only show in the gitian produced files. This shouldn't effect what users would see from -version or in the About window.

@laanwj

This comment has been minimized.

Copy link
Member

commented Oct 31, 2018

Concept ACK

  • maybe not for this PR, but would also make sense to show the RC information in the about: dialog and the log
  • probably needs an update to doc/release-process.md to update this new setting between rcs
  • this naming might need updates at the side of bitcoin.org (@wbnns) and bitcoincore.org (@harding) though as RCs are never linked from the webpage, and .dot releases are extremely are, that might amount to nothing or at least not be urgent. Normal releases will not change name, correct?
@harding

This comment has been minimized.

Copy link
Member

commented Oct 31, 2018

For BitcoinCore.org, as @laanwj mentions, the regular content part of the website doesn't currently have any pages that link directly to RCs, so no changes are necessary as long as the final release files continue to use the same naming scheme.

@laanwj laanwj added this to the 0.18.0 milestone Nov 1, 2018

@wbnns

This comment has been minimized.

Copy link
Contributor

commented Nov 1, 2018

Should be okay for bitcoin.org as well, thanks.

@achow101

This comment has been minimized.

Copy link
Member Author

commented Nov 1, 2018

I've updated release-process.md to say that CLIENT_VERSION_RC needs to be updated before each RC.

Normal releases will not change name, correct?

Correct.

@laanwj

This comment has been minimized.

Copy link
Member

commented Nov 1, 2018

@harding @wbnns thanks for weighing in

utACK 75a4bf6

@laanwj

This comment has been minimized.

Copy link
Member

commented Nov 5, 2018

@theuni I suppose you're ok with this?

@laanwj laanwj merged commit 75a4bf6 into bitcoin:master Nov 23, 2018

2 checks passed

continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details

laanwj added a commit that referenced this pull request Nov 23, 2018

Merge #14612: Include full version number in released file names
75a4bf6 Update release-process.md to include RC version bumping (Andrew Chow)
04b0bc7 build: include rc number in version number (Andrew Chow)
895e6bb build: if VERSION_BUILD is non-zero, include it in the package version (Andrew Chow)

Pull request description:

  As noted on IRC, the filenames of the gitian build results do not contain the 4th digit of the version number if it has one, e.g. 0.17.0.1 produces files with the number 0.17.0. Furthermore, when RC's are built, the resulting filenames are of the release version and do not include `rc` in them. This occurs because `configure.ac` is written to create version numbers of the form `major.minor.rev` instead of `major.minor.rev.build` and without any rc version as it does not handle rc numbers.

  This PR changes `configure.ac` to include the build number if it is greater than 0. It will also include the rc number if it is greater than 0. So the filenames of the gitian builds will now contain the full version number.

  This behavior can be tested by setting `_CLIENT_VERSION_BUILD` and `_CLIENT_VERSION_RC` to non-zero values and then doing `make dist`. A tar file should be created with the correct versioning.

Tree-SHA512: b77990485f2c7770be897dc136737cd805306afff9882ebef7170741f363203587356ccf8bec83163268ace1bd77433fbd2ba8c213f993677bfb867d99a0bbe7

@bitcoin bitcoin deleted a comment from DrahtBot Nov 23, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.