Opened 9 years ago

Closed 9 years ago

#302 closed defect (fixed)

review: bind10 (bob) shows an old version

Reported by: jinmei Owned by: UnAssigned
Priority: low Milestone: y2 6 month milestone
Component: b10-auth Version:
Keywords: Cc:
CVSS Scoring: Parent Tickets:
Sensitive: no Defect Severity:
Sub-Project: Feature Depending on Ticket:
Estimated Difficulty: 0.0 Add Hours to Ticket: 0
Total Hours: 0 Internal?: no

Description

% ./src/bin/bind10/run_bind10.sh -v
BIND 10 v20100701

I believe we should use PACKAGE_VERSION set in the configure script.

Attached patch does that. Could someone check it? I think it's worth merging for this release.

(for that matter we should update configure.ac)

Subtickets

Attachments (2)

bind10.diff (776 bytes) - added by jinmei 9 years ago.
bind10.2.diff (1.5 KB) - added by jreed 9 years ago.

Download all attachments as: .zip

Change History (13)

Changed 9 years ago by jinmei

comment:1 Changed 9 years ago by jinmei

oops bad example. it was the output if the proposed patch applied.

This is what is currently displayed:

% ~/opt/sbin/bind10 -v
BIND 10 v20100531
...

comment:2 Changed 9 years ago by jinmei

  • Owner set to UnAssigned
  • Status changed from new to reviewing

comment:3 Changed 9 years ago by jreed

This probably should output two version numbers.

One for the specific tool, and the other for the BIND 10 as a whole.

I have an item on my release engineering checklist to make sure the version is increased.

I am working on alternate patch.

Changed 9 years ago by jreed

comment:4 follow-up: Changed 9 years ago by jreed

Slightly different patch attached. It has two versions. bind10 version is from last bind10.py.in change.

comment:5 Changed 9 years ago by jreed

And if okay, do the same thing for b10-msgq (version probably is 20100630) and other programs.

comment:6 in reply to: ↑ 4 Changed 9 years ago by jinmei

Replying to jreed:

Slightly different patch attached. It has two versions. bind10 version is from last bind10.py.in change.

Ah, I didn't realize it was intended to be a module specific version.

But I'm still not sure why we need to print these two. My recollection of the past discussion on this is that if someone wants to run a differet version for some specific program or module (e.g. upgrading only b10-auth) we'd like to see that different version from the output of the specific program, while others still show the common version. Is that correct?

If so, it seems sufficient to me to build each program using the top level PACKAGE_VERSION.

On a related matter, I basically don't think it a good idea to distribute the source of this type of information (which is needed to be updated by hand). It can be very easily outdated.

Anyway, I now see this is not as trivial as I original thought, and I guess it should probably go to the next release.

comment:7 Changed 9 years ago by jinmei

  • Milestone changed from 06. 4th Incremental Release to y2 6 month milestone

comment:8 Changed 9 years ago by jreed

  • Owner changed from UnAssigned to jreed
  • Status changed from reviewing to accepted

comment:9 Changed 9 years ago by jreed

  • Owner changed from jreed to UnAssigned
  • Status changed from accepted to assigned

I made a branch for this a few weeks ago. See trac302. Needs review. This has no unit tests.

(No changelog entry provided yet.)

comment:10 Changed 9 years ago by jelte

  • Status changed from assigned to reviewing

review status seems to have gotten lost, resetting to review

comment:11 Changed 9 years ago by jreed

  • Resolution set to fixed
  • Status changed from reviewing to closed

I committed my changes to trunk. Discussed with jelte on jabber.

Later add version details to other modules using same format.

or discuss to reconsider not doing any per-module versions.

Note: See TracTickets for help on using tickets.