Daniel Leidert wrote: > Nicolas Vervelle wrote: > >> Bob Hanson wrote: >> >>> the revision numbers change more rapidly than the release >>> numbers. >>> > > You change the version number almost always with a change in > the development tree. There is no "real" release you do. So > IMHO there is no big difference between release and revision > numbers here. So I thought, that using the global > Release-version as minor version number probably more fits this > behaviour. It would even allow a faster bug-tracking in the > development tree, if the user can provide the revision number in > the bug-report. > > >> Yes, and it still requires to modify JmolConstants.java (or to force >> commit) to update the $..$ fields. >> > > No. I spoke about the global Release-number SVN provides (SVN > counts up the Release number, as you know). AFAIK > it is possible to get this one. $Release$ may be the wrong > keyword for it. > My knowledge of SVN is limited, so I may be wrong but here's what I think about how it is working : - there's indeed a global release number - a $...$ field in a file is replaced only when a file is committed - the version of a file is the last release number where it was modified (if we forget about branches)
That's why I thought we need to commit a file to get an update of the $...$ field. If you know how to do it otherwise, that may be interesting. Providing the correct revision number in the release could be useful, but I don't know how to. Nico ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Jmol-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jmol-developers
