--version prints more and less than it should

Bug #1025848 reported by Reijo Tomperi
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
widelands
Fix Released
Low
Unassigned

Bug Description

When given --version from command line, widelands prints also the --help texts and other information. Maybe GNU coding style guide should be followed here?

Also, the current version info is not very user friendly. I can't tell from this am I using version prior release 17 or not:
"No version file found
This is Widelands-bzr6413[trunk](Release)"

http://www.gnu.org/prep/standards/html_node/_002d_002dversion.html#g_t_002d_002dversion

Revision history for this message
Shevonar (shevonar) wrote :

I agree with you that the usage information should not be printed. Therefore I am setting this to confirmed.

I don't see why you think it is not user friendly? For build 17 --version says:
"No version file found
This is Widelands-build-17(Release)"
For test builds only the bzr revision is of interest so why should there be more information? Could please tell more precisely what you expect?

Changed in widelands:
status: New → Confirmed
importance: Undecided → Low
Revision history for this message
Reijo Tomperi (aggro80) wrote :

About "No version file found". User has no clue why such error is printed on his/her screen, how serious problem it is, and what should be done to fix it, especially since the version number is printed there. I don't have any idea either, so I don't know how to fix it, but as version information seems to be very nicely found despite of this error message, I can only assume that the error message can be just removed. If removing is not possible, the error message can perhaps be improved to answer (some of) these questions.

"This is Widelands-bzr6413[trunk](Release)" E.g. Firefox shows following information in nightly builds "15.0a1 (2012-04-25)". This tells me that this is an alpha release for something that will be Firefox 15 once released. It also tells me that the build is several months old. Providing the bzr revision does no harm as it probably makes bug reporting much easier. Even small improvements (e.g. the date) would be great.

To give exact answer to your question, I would be happy to see something like this "Widelands-build-18-alpha-bzr6413 (2012-04-25)". [trunk](Release) can be there also, thought the "Release" made me think that it was actually official release, but version number was just not printed correctly because of the above error message.

Revision history for this message
Nasenbaer (nasenbaer) wrote :

I as well agree, that the usage information should not be printed and that the warning does not make a lot of sense.

Anyway concerning your ideas in #2: Widelands is still in a alpha state - some of the features planned for a final release are not yet implemented, and quite a hand full of known bugs are left inside the game in each official build. So an output like "build-18-alpha" would be kind of unlogical - an alpha of alpha software.

Further the bzr version alone does not say that much about the development state, as Widelands is developed in trunk + different branches, so a bzr version from one of the branches can show a completely different development state, although it has the same version number than another version from trunk - that's why there is the [branchname] tag included.

And last but not least: A person running a development version must have thought about compiling Widelands him-/herself or downloading an inofficial build a some point. And if he/she just downloads it *somewhere* without checking the date or even the contense of the file... seriously that's nothing we can take care of ;)

Btw. (Release) means "no debug symbols" in difference to (Debug)

So please don't get me wrong - your bug is 100% valid. Thank you for posting! :)
I just want to say, that always taking care about a 100% understandable version number in every state of development is just over prowered for a game like Widelands, on which just 1-10 person a month are working on. ;)

Revision history for this message
Shevonar (shevonar) wrote :

I totally agree with Nasenbaer. Couldn't have explained it better. Once there is a version 1.0 we have to rethink the how the version number of Widelands is named and increased but until then it is fine as it currently is (except of the unnecessary information like usage and error message).

Revision history for this message
Nasenbaer (nasenbaer) wrote :

Fix was committed in bzr rev6425. The --version output of my version looked like:

Widelands bzr6425[widelands](Debug)

Closing this report as fix committed. :)

Changed in widelands:
status: Confirmed → Fix Committed
milestone: none → build18-rc1
Revision history for this message
SirVer (sirver) wrote :

Released in build-18 rc1.

Changed in widelands:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Related blueprints

Remote bug watches

Bug watches keep track of this bug in other bug trackers.