On Tue, Nov 13, 2012 at 03:57:55PM -0800, David Wolfskill wrote: > I like the idea, but I have long found the idea of putting this type of > logic (including VCS-awareness) in newvers.sh itself something that is > prone to turn what should be a rather simple script into a ... mess. I don't think newvers.sh is a mess (yet) and I find current features highly desirable. > What I have been using for several months has been a modified newvers.sh > that uses an externally-defined function (from a file that is sourced) > to handle whatever VCS-specific things I think are appropriate. (Thus, > folks who want to use one VCS don't need to have newvers.sh test for > VCSen they don't use; they could also provide a sample file that > provides the function. An installation could use a symlink to point to > the function definition of choice.... We could even have a "kitchen > sink" default, that goes through all the hoops & gyrations the current > code does, if folks want that.) newvers.sh definitely should continue to work without hints on cvs/svn/git. Moving checks to different files seems completely unnecessary for me as I don't find current checks expensive. But if you do the work I see nothing wrong with it. :) (but please note I'm in no position to accept your changes) Given that, low-cost support for custom version strings could look like this: after all standard values are filled, prepare complete version string, then source custom script if it exists. This way your script has access to everything that newvers.sh was able to determine and to complete version string, and you are free to change it however you want using detected revision/compiler/whatever or completely new data. -- Mateusz Guzik <mjguzik gmail.com>Received on Thu Nov 15 2012 - 13:08:34 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:32 UTC