Fix documenting version numbers about jwst HOT 14 CLOSED

this line and the one below

from jwst.

At build-time the version data is recorded at the top-level of the jwst
package:

from jwst.version import *
from .version import *
from ..version import * #(or whatever level of relative '.'s)

__version_commit__ replaces __svn_revision__

version.py snippet:

__version__ = '0.6.0noop.dev107'
__version_short__ = '0.6.0noop'
__version_long__ = '0.6.0noop-107-gf845387d'
__version_post__ = '107'
__version_commit__ = 'f845387d'
__version_date__ = '2016-06-13 17:35:10 -0400'
__version_dirty__ = False
__build_date__ = '2016-06-13'
__build_time__ = '17:37:19.913442'
__build_status__ = 'release' if not int(__version_post__) > 0 \
     and not __version_dirty__ \
     else 'development'

On 6/13/16 5:48 PM, Nadia Dencheva wrote:

|stpipe.Step.run| records the version of the software used as
|svn_revision|.
@jhunkeler https://github.com/jhunkeler What is the way to get the
equivalent number now?

I'm commenting out this line in stpipe for now to try to get a clean
run of all tests.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#57, or mute the thread
https://github.com/notifications/unsubscribe/AAd95aqCsznKRLMWbrXJ4kRcEw6hmQjhks5qLdAmgaJpZM4I0xP6.

from jwst.

^ replying by email breaks markdown. Good to know.

At build-time the version data is recorded at the top-level of the jwst
package:

from jwst.version import *
from .version import *
from ..version import * #(or whatever level of relative '.'s)

__version_commit__ replaces __svn_revision__

version.py snippet:

__version__ = '0.6.0noop.dev107'
__version_short__ = '0.6.0noop'
__version_long__ = '0.6.0noop-107-gf845387d'
__version_post__ = '107'
__version_commit__ = 'f845387d'
__version_date__ = '2016-06-13 17:35:10 -0400'
__version_dirty__ = False
__build_date__ = '2016-06-13'
__build_time__ = '17:37:19.913442'
__build_status__ = 'release' if not int(__version_post__) > 0 \
     and not __version_dirty__ \
     else 'development'

from jwst.

Thanks. It shoul dbe resolved by #58

from jwst.

version_commit certainly seems to be the closest thing to the equivalent of the SVN revision number, so that seems appropriate to use in place of svn_revision. Just curious, what does the date/time value in version_date refer to? Is it the time at which the commit was done?

from jwst.

@hbushouse Yes, __version_date__ refers to the timestamp of the commit. For example, if you were to check out the parent tag using git checkout 0.6.0noop and run the setup script, the generated version.py will read:

__version__ = '0.6.0noop'
__version_short__ = '0.6.0noop'
__version_long__ = '0.6.0noop-0-g5915b0e9'
__version_post__ = '0'
__version_commit__ = '5915b0e9'
__version_date__ = '2016-06-08 14:23:41 -0400'
__version_dirty__ = False
__build_date__ = '2016-06-13'
__build_time__ = '22:58:53.064910'
__build_status__ = 'release' if not int(__version_post__) > 0 \
    and not __version_dirty__ \
    else 'development'

from jwst.

What are we going to do about the CAL_SVN keyword? Pretend the "SVN" doesn't mean anything? Delete it? Rename it?

from jwst.

I'm thinking of renaming the keyword to something like "CAL_GIT" (CAL_HASH, CALCOMMT?) and populate it with the value of __version_commit__.

from jwst.

On 06/14/2016 08:35 AM, Howard Bushouse wrote:

I'm thinking of renaming the keyword to something like "CAL_GIT"
(CAL_HASH, CALCOMMT?) and populate it with the value of
|version_commit|

How about CAL_VCS? If we wrote a keyword VERSION_COMMIT to the FITS
header, maybe nobody would notice.

Phil

from jwst.

I agree that something like VERSION_COMMIT (which we can't use anyway, because it's too many characters) or GITCOMMIT etc. is too generic, because there are also keywords that give the version numbers of things like CRDS and SDP. So we do need to classify it under the "CAL" hierarchy somehow. What would "VCS" in "CAL_VCS" stand for?

from jwst.

On 06/14/2016 08:51 AM, Howard Bushouse wrote:

I agree that something like VERSION_COMMIT (which we can't use anyway,
because it's too many characters) or GITCOMMIT etc. is too generic,
because there are also keywords that give the version numbers of
things like CRDS and SDP. So we do need to classify it under the "CAL"
hierarchy somehow. What would "VCS" in "CAL_VCS" stand for?

Version control system. I didn't think it was a good idea to tie a
keyword to a particular VCS. If we'll have lots of different version
keywords, we could use the comment section to explains what it refers to.

from jwst.

I am not sure what we talked about here was resolved except the original question.
I think it would be good to have a description comment in the file for each of the variables.

Other than that I have no further comments. @hbushouse feel free to close if you think this has been resolved.

from jwst.

I think that using version_commit to populate the keyword value is OK, but we should still change the name of the keyword (CAL_SVN) to something like CAL_VCS and update the keyword comment. So let's keep this open for B7.1.

from jwst.

Fixed by #1388

from jwst.