Project

General

Profile

Bug #17012

Updated by Ward Vandewege about 4 years ago

The build/version-at-commit.sh script doesn't handle the scenario right after a major release well. 

 For code that hasn't changed since the major release, it generates version numbers without taking the major release tag into account. 

 For instance; as of commit c6c2f3518bc745eed95b5f5b81db5d17db4366ff on master, which is after the fork point of the 2.1-dev branch, these packages were generated for debian10: 

 <pre> 
 arvados-api-server_2.1.0-1_amd64.deb 
 arvados-client_2.1.0~dev20201012021212-1_amd64.deb 
 arvados-controller_2.1.0~dev20201012021212-1_amd64.deb 
 arvados-dispatch-cloud_2.1.0~dev20201012021212-1_amd64.deb 
 arvados-docker-cleaner_2.2.0~dev20201015145956-1_amd64.deb 
 arvados-git-httpd_2.1.0~dev20201012021212-1_amd64.deb 
 arvados-health_2.1.0~dev20201012021212-1_amd64.deb 
 arvados-src_2.2.0~dev20201015145956-1_all.deb 
 arvados-sync-groups_2.2.0~dev20201013141632-1_amd64.deb 
 arvados-workbench_2.1.0~dev20201012021212-1_amd64.deb 
 arvados-ws_2.1.0~dev20201012021212-1_amd64.deb 
 crunch-dispatch-local_2.1.0~dev20201012021212-1_amd64.deb 
 crunch-dispatch-slurm_2.1.0~dev20201012021212-1_amd64.deb 
 crunch-run_2.1.0~dev20201012021212-1_amd64.deb 
 crunchstat_2.1.0~dev20201012021212-1_amd64.deb 
 keep-balance_2.1.0~dev20201012021212-1_amd64.deb 
 keep-block-check_2.1.0~dev20201012021212-1_amd64.deb 
 keep-exercise_2.1.0~dev20201012021212-1_amd64.deb 
 keepproxy_2.1.0~dev20201012021212-1_amd64.deb 
 keep-rsync_2.1.0~dev20201012021212-1_amd64.deb 
 keepstore_2.1.0~dev20201012021212-1_amd64.deb 
 keep-web_2.1.0~dev20201012021212-1_amd64.deb 
 libpam-arvados-go_2.1.0~dev20201012021212-1_amd64.deb 
 python3-arvados-cwl-runner_2.2.0~dev20201015145956-1_amd64.deb 
 python3-arvados-fuse_2.2.0~dev20201015145956-1_amd64.deb 
 python3-arvados-python-client_2.2.0~dev20201015145956-1_amd64.deb 
 python3-crunchstat-summary_2.2.0~dev20201015145956-1_amd64.deb 
 </pre> 

 You can see that the python packages have a correct version number that takes the release into account (2.2.0~dev20201015145956), which is because there are some commits in master (post the 2.1-dev branch fork) that touch the Python part of the codebase. 

 For other parts of the codebase, a version string is generated that starts with 2.1.0~dev, which is not ideal. 

 For the API server package, it even generated the version string 2.1.0, because the calculated version for that package and its dependencies happens to be the commit that is tagged with the 2.1.0 version. 

Back