I am about to upload an updated tcltkgrass for 5.7 to the CVS. Glynn Clements helped revamp gui.tcl after I cleaned out about 2/3 of the code because it is unused now. menu.tcl also has some updates to go along with this clean up. Both deserve a change in version numbers. Internally (i.e., in the header to the program), menu.tcl is going from 4.0 to 4.1.
So here is my question. The CVS was started considerably after the GRASS project and so it’s version numbers are quite different from the internal version numbers, at least for the modules that I’ve been dealing with. I was wondering:
Would it be a good idea to change the CVS version numbers to match the internal version numbers with the idea that they stay in sync thereafter and can help others see where the module revisions are at? Or is this a bad idea for some reason?
Would it be a good idea to give all modules of tcltkgrass the same version number, updating it across all modules as needed? Currently, menu.tcl is at 4.0 and gui.tcl is at 1.1. Or is it better if each module of this package gets version numbers as the individual module is changed?
Michael
Michael Barton, Professor & Curator
School of Human Origins, Cultures, & Societies
Arizona State University
Tempe, AZ 85287-2402
USA
I am about to upload an updated tcltkgrass for 5.7 to the CVS. Glynn
Clements helped revamp gui.tcl after I cleaned out about 2/3 of the code
because it is unused now. menu.tcl also has some updates to go along with
this clean up. Both deserve a change in version numbers. Internally (i.e.,
in the header to the program), menu.tcl is going from 4.0 to 4.1.
So here is my question. The CVS was started considerably after the GRASS
project and so it¹s version numbers are quite different from the internal
version numbers, at least for the modules that I¹ve been dealing with. I was
wondering:
1. Would it be a good idea to change the CVS version numbers to match the
internal version numbers with the idea that they stay in sync thereafter and
can help others see where the module revisions are at? Or is this a bad idea
for some reason?
2. Would it be a good idea to give all modules of tcltkgrass the same
version number, updating it across all modules as needed? Currently,
menu.tcl is at 4.0 and gui.tcl is at 1.1. Or is it better if each module of
this package gets version numbers as the individual module is changed?
Are you referring to CVS revision numbers, as listed by "cvs log" and
by "$Id: ... $" in file comments? Or something else?
There isn't much that can realistically be done about CVS revision
numbers; those are generated automatically.
On my CVS client it looks like I can give a file a specified new revision
number, overriding the normal CVS incremental revision assignment. I haven't
tried it. But if it is possible, do you think it is OK to do this?
Michael
On 8/17/04 12:07 PM, "Glynn Clements" <glynn.clements@virgin.net> wrote:
Are you referring to CVS revision numbers, as listed by "cvs log" and
by "$Id: ... $" in file comments? Or something else?
There isn't much that can realistically be done about CVS revision
numbers; those are generated automatically.
Michael Barton wrote:
I am about to upload an updated tcltkgrass for 5.7 to the CVS. Glynn
Clements helped revamp gui.tcl after I cleaned out about 2/3 of the code
because it is unused now. menu.tcl also has some updates to go along with
this clean up. Both deserve a change in version numbers. Internally (i.e.,
in the header to the program), menu.tcl is going from 4.0 to 4.1.
So here is my question. The CVS was started considerably after the GRASS
project and so it¹s version numbers are quite different from the internal
version numbers, at least for the modules that I¹ve been dealing with. I was
wondering:
1. Would it be a good idea to change the CVS version numbers to match the
internal version numbers with the idea that they stay in sync thereafter and
can help others see where the module revisions are at? Or is this a bad idea
for some reason?
2. Would it be a good idea to give all modules of tcltkgrass the same
version number, updating it across all modules as needed? Currently,
menu.tcl is at 4.0 and gui.tcl is at 1.1. Or is it better if each module of
this package gets version numbers as the individual module is changed?
______________________________
Michael Barton, Professor & Curator
School of Human Origins, Cultures, & Societies
Arizona State University
Tempe, AZ 85287-2402
USA
On my CVS client it looks like I can give a file a specified new revision
number, overriding the normal CVS incremental revision assignment. I haven't
tried it. But if it is possible, do you think it is OK to do this?
I don't really see much point. If you want to identify a distinct
"version" of a particular module, it's better to use a tag.
If you wanted to all of the current tcltkgrass source files to have a
revision of 4.1, you would have to commit all of the files, even those
which haven't changed. Also, the next time someone commits a
particular file, it would become revision 4.2. Unless you re-commit
the entire tcltkgrass source tree every time, the revisions will
quickly become out of sync.
Also, according to the CVS documentation, you can't use this feature
on a branch, only on the trunk.
I don't know of any other project which determines CVS revision
numbers manually.
I am about to upload an updated tcltkgrass for 5.7 to the CVS. Glynn
Clements helped revamp gui.tcl after I cleaned out about 2/3 of the
code because it is unused now. menu.tcl also has some updates to go
along with this clean up. Both deserve a change in version numbers.
Internally (i.e., in the header to the program), menu.tcl is going
from 4.0 to 4.1.
I think these were mostly useful in the days before CVS and version
history had to be stored in comments in the file itself. Nowadays
keeping them up just means more work for everybody with little return,
IMO.
You can add the CVS tag $Id$ to files (but avoid putting that on the
first line) to have CVS update the version number automatically. This
can lead to confusion problems when files are merged from 5.3->5.7 or
tagged for release(??), but I think it's better than a) nothing b)
unmaintained independent versioning within files.
another issue:
we now have two different file with the same name:
grass51/lib/gis/gui.tcl # GUI boilerplate
grass51/gui/tcltkgrass/main/gui.tcl # tcltk menu control code
Perhaps we should consider renaming one of them (the newer one) to
avoid future confusion?
Then again, we have hundreds of Makefiles and description.html files
around so maybe it isn't that horrible.