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.

Sign up for GitHub

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

Jump to bottom

Consider removing "VXL Nightly Date Stamp" #97

Closed
hjmjohnson opened this issue Jan 11, 2016 · 13 comments
Closed

Consider removing "VXL Nightly Date Stamp" #97

hjmjohnson opened this issue Jan 11, 2016 · 13 comments

Comments

@hjmjohnson
Copy link
Contributor

The nightly "VXL Nightly Date Stamp" commits seem like unnecessary noise in the commit messages.

commit f2f0bf1
Author: Kitware Robot kwrobot@kitware.com
Date: Fri Jan 8 00:01:23 2016 -0500

VXL Nightly Date Stamp

Is there a rational for having this in a git based source code repository?

If not, could we remove it?
@hjmjohnson
Copy link
Contributor Author

@thewtex

Matt, Would you mind commenting on the pro's/con's of an automated timestamp commit?

@billhoffman
Copy link
Contributor

I think it allows for the dashboard to do nightly builds that are the same git hash. So, I think it is still a useful thing. Although, in CMake I think we use a moving tag. @bradking what do you think?

@andyneff
Copy link
Contributor

I would prefer a moving tag/branch much more.

@thewtex
Copy link
Contributor

thewtex commented Jan 11, 2016

In ITK, we use a "nightly-master" branch to do nightly builds on the same commit. It works well.

@bradking
Copy link
Contributor

The nightly date stamp commit is done in order to provide a detailed API version number for clients to test. Originally it was added because ITK kept getting broken by changes to VXL's API and needed a way to detect which APIs are available in a version-granular way in order to allow ITK to build against an arbitrary system-provided version of VXL. I don't think ITK has needed to have such a check added in a long time, but that may be because VXL development has been slow.

I have no opinion on whether we should keep it.

@thewtex
Copy link
Contributor

thewtex commented Jan 11, 2016

Since ITK does not use it anymore, +1 for removing it.

@bradking
Copy link
Contributor

For reference, ITK uses the vxl version date in a few places:

$ cd ITK
$ git grep VXL_VERSION_DATE
Modules/Core/Common/include/itkArray.h:#if VXL_VERSION_DATE_FULL < 20110428
Modules/Core/Mesh/include/itkSimplexMesh.hxx:#if VXL_VERSION_DATE_FULL > 20040406
Modules/Core/Mesh/include/itkSimplexMeshAdaptTopologyFilter.h:#if VXL_VERSION_DATE_FULL > 20040406
Modules/Core/Mesh/src/itkSimplexMeshGeometry.cxx:#if VXL_VERSION_DATE_FULL > 20040406
Modules/Numerics/FEM/src/itkFEMLinearSystemWrapperVNL.cxx:#if VXL_VERSION_DATE_FULL >= 20100109
Modules/Segmentation/DeformableMesh/include/itkDeformableSimplexMesh3DFilter.hxx:#if VXL_VERSION_DATE_FULL > 20040406
Modules/ThirdParty/VNL/src/vxl/core/vxl_version.h:#define VXL_VERSION_DATE_YEAR 2011
Modules/ThirdParty/VNL/src/vxl/core/vxl_version.h:#define VXL_VERSION_DATE_MONTH 04
Modules/ThirdParty/VNL/src/vxl/core/vxl_version.h:#define VXL_VERSION_DATE_DAY 28
Modules/ThirdParty/VNL/src/vxl/core/vxl_version.h:#define VXL_VERSION_DATE \
Modules/ThirdParty/VNL/src/vxl/core/vxl_version.h:  VXL_VERSION_TO_STRING(VXL_VERSION_DATE_YEAR-VXL_VERSION_DATE_MONTH-VXL_VERSION_DATE_DAY)
Modules/ThirdParty/VNL/src/vxl/core/vxl_version.h:#define VXL_VERSION_DATE_FULL \
Modules/ThirdParty/VNL/src/vxl/core/vxl_version.h:  VXL_VERSION_DATE_FULL0(VXL_VERSION_DATE_YEAR, \
Modules/ThirdParty/VNL/src/vxl/core/vxl_version.h:                         VXL_VERSION_DATE_MONTH, \
Modules/ThirdParty/VNL/src/vxl/core/vxl_version.h:                         VXL_VERSION_DATE_DAY)
Modules/ThirdParty/VNL/src/vxl/core/vxl_version.h:#define VXL_VERSION_DATE_FULL0(y,m,d) VXL_VERSION_DATE_FULL1(y,m,d)
Modules/ThirdParty/VNL/src/vxl/core/vxl_version.h:#define VXL_VERSION_DATE_FULL1(y,m,d) y##m##d
Modules/ThirdParty/VNLInstantiation/src/vnl_c_vector+longlong-.cxx:#if VXL_VERSION_DATE_FULL < 20120316
Modules/ThirdParty/VNLInstantiation/src/vnl_c_vector+ulonglong-.cxx:#if VXL_VERSION_DATE_FULL < 20120316
Modules/ThirdParty/VNLInstantiation/src/vnl_matrix+longlong-.cxx:#if VXL_VERSION_DATE_FULL < 20120316
Modules/ThirdParty/VNLInstantiation/src/vnl_matrix+ulonglong-.cxx:#if VXL_VERSION_DATE_FULL < 20120316
Modules/ThirdParty/VNLInstantiation/src/vnl_vector+longlong-.cxx:#if VXL_VERSION_DATE_FULL < 20120316
Modules/ThirdParty/VNLInstantiation/src/vnl_vector+ulonglong-.cxx:#if VXL_VERSION_DATE_FULL < 20120316

The most recent one is 20120316 which was a change to VNLs set of instantiations to include long long types.

@hjmjohnson
Copy link
Contributor Author

From: Chuck Atkins chuck.atkins@kitware.com
Date: Monday, January 18, 2016 at 11:22 AM
To: Hans Johnson hans-johnson@uiowa.edu
Cc: "vxl-users@lists.sourceforge.net" vxl-users@lists.sourceforge.net, "vxl-maintainers@lists.sourceforge.net" vxl-maintainers@lists.sourceforge.net
Subject: Re: [Vxl-maintainers] Remove the "VXL Nightly Date Stamp"

I believe the rationale is to be able to have version information from a source tarball taken at any given point in history, not jus a release, without the repository metadata. Think of using 'git archive' to generate a source tarball.

hjmjohnson added a commit to InsightSoftwareConsortium/vxl that referenced this issue Feb 28, 2016
@hjmjohnson
ENH: Use git introspection to get version information
6b2c9e6 
This addresses issue vxl#97. By using git commands
to interrogate and extract version and date information
we can automatically use the git tagging system to
keep track of software version changes.
@bradking
Copy link
Contributor

Extracting the date from the Git commit object gives one a date, but it is not representative of the version of vxl. I could take a 5 year old commit from vxl, start a branch, create one commit, and then build. Suddenly it reports as a modern version of vxl even though it is not.

The only way to have a meaningful version number is to have a defined development path in which it is updated. With arbitrary branching such a path can be well-defined only by explicit commits that do the version updates.

If nightly commits are too noisy compared to the rest of the development pace then we could switch to a longer time interval.

@andyneff
Copy link
Contributor

You could always just ask git "What version from master did this branch come from"

diff -u <(git rev-list --first-parent HEAD) \
        <(git rev-list --first-parent master) | \
        sed -ne 's/^ //p' | head -1

[1] - source

@bradking
Copy link
Contributor

just ask git "What version from master did this branch come from"

That assumes that the local master matches the upstream master. Local commits on the branch will break it. Also tarballs from git archive will not have this information even if they encoded the date of the commit from which they were built.

This is a general problem with distributed version control. Every project has the same problem, but it is particularly problematic for vxl because:

  • Stable versioned releases are not made often
  • Backward-incompatible changes occur
  • Clients frequently build against development versions

The nightly commit serves as an automated version number in place of manually-made release versions. The commit noise is a cost we pay to support clients without having to instead pay the cost of preparing releases regularly.

@hjmjohnson
Copy link
Contributor Author

It seems like we are going to live with these nightly commits.

Closing due to inactivity for several years.

@sanjayankur31
Copy link
Contributor

Sorry for bumping this old ticket but I'm still trying to get my head around how an automated time stamp functions as an API/ABI version. The nightly commit gives no information at all about such a change. All it says is that "this is the vxl version in use", and that really can be done using git commit data---it's what it is for.

just ask git "What version from master did this branch come from"

That assumes that the local master matches the upstream master. Local commits on the branch will break it. Also tarballs from git archive will not have this information even if they encoded the date of the commit from which they were built.

There are many solutions of ensuring that a project is correctly linked to a particular "version" of a dependency---such as git submodules.

This is a general problem with distributed version control. Every project has the same problem, but it is particularly problematic for vxl because:

  • Stable versioned releases are not made often
  • Backward-incompatible changes occur

These are handled by manually bumping the soname version to signifiy a new API/ABI, aren't they? The manual bump clearly tells clients that something has changed, while the automated commit does not---it obfuscates this information since one has to go through the git commit log to figure out the changes.

  • Clients frequently build against development versions

Yes, but development versions also carry API/ABI information in the form of soname versioning.

The nightly commit serves as an automated version number in place of manually-made release versions. The commit noise is a cost we pay to support clients without having to instead pay the cost of preparing releases regularly.

Not really---unless the API/ABI has changed, a release isn't required. Clients can link against a development snapshot without any trouble if such a change hasn't been made.

Can we consider moving to semantic versioning maybe? https://semver.org/

#624 and #626 are related to this (and are how I ran into this issue).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@thewtex @bradking @sanjayankur31 @billhoffman @hjmjohnson @andyneff