All: I simply changed the svn:keyword part to allow autogeneration of Id's again, because I think they are useful for documentation purposes.
Then I realized that it broke everything because the $VERSION was formerly being generated from $Revision$ The easiest way to fix that, was to delete the VERSION lines from everything. Being that SQL::Translator is distributed as a huge monolithic module, I didn't think this would have any noticeable effect on the module. None of this will matter much, because if things go the way I envision them going, the modules will be split into their own packages (and a Bundle or similar package for the entire SQLT install). This will allow each version number to be tracked independently and yes, each version number will be set on a per-module basis. However, my one concern is that there are no similar provisions to set module versions in SVN, that are also compatible with the PAUSE indexer. So I would suggest that we'd have to increment versions manually when making large commits, which could be problematic. But I think this should be done as part of the packaging process. Cheers, Jonathan On Thu, Feb 12, 2009 at 8:27 AM, Jess Robinson <casta...@desert-island.me.uk> wrote: > > > On Thu, 12 Feb 2009, Jess Robinson wrote: > >> On Sat, 17 Jan 2009, Darren Chamberlain wrote: >> >>> I'd like to see $VERSION be the same in every module, >>> for consistency and simplicity. Actually, while we're at it, I'd like >>> the pod for each module to have the version number, too, something >>> like "This describes $MODULE version $VERSION", so that when the docs >>> get distributed separately, like on search.cpan.org. >> >> Or, you could patch cpan/perldoc code to add that sorta message. >> >> The downside is, if every module has the same version, the one of the >> dist, then one needs to update every single file when releasing a new >> version, whether the actual code in it changed or not. > > Hmm, just occurs to me that a lot saner would be: > > "This module supports MySQL versions X, Y, X" or similar... Then we'd > could point and laugh at people who complain about them not working with > newer ones ;) > > Jess > > > ------------------------------------------------------------------------------ > Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) > software. With Adobe AIR, Ajax developers can use existing skills and code to > build responsive, highly engaging applications that combine the power of local > resources and data with the reach of the web. Download the Adobe AIR SDK and > Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com > -- > sqlfairy-developers mailing list > sqlfairy-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/sqlfairy-developers > ------------------------------------------------------------------------------ Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com -- sqlfairy-developers mailing list sqlfairy-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sqlfairy-developers
