If no one else has a supporting/dissenting opinion on this I suppose I will have to defer to the status quo as proposed by wes (5.04000001)...though this seems over large and over restrictive on what libsnmp releases it will run with...if you have an opinion, now might be a good time to share it.
...granted I am missing some history and description of the current module version release philosophy... -G G. S. Marzot wrote: > > The current perl module versioning (5.0301001) seems bit cumbersome and > susceptible to error/confusion - perhaps because I did not find any documented > policy on version compatibility and maintenance and missed previous > discussions. > > The following is a proposed scheme and policy to simplify and clarify the > behavior or perl module versioning wrt to net-snmp release versioning. > > The model provided by dynamic library usage seems to capture the relationship > between the SNMP module and the net-snmp library with which it links. As long > as > proper discipline is shown in the evolution of libsnmp the perl module can > use > a fixed logic for determining if a given libsnmp release is compatible > > certain assumptions can make managing the version numbers easier, more > flexible > without any loss of capability and a reasonable degree of protection against > inadvertent incompatibility. > > assumptions: > > 0) it is not a good thing to change a version number on source that has not > changed - even worse not to change the version stamp on source that has > changed. > > 1) it is good to have as high a degree of similarity between perl mod version > numbers and the net-snmp version numbers with which it is bundled (within the > constraint that perl modules are restricted (highly encouraged) to use a float > format for version numbers - the real culprit here). > > 2) the perl module is released is rev'd less frequently than the net-snmp > package as a whole (and certainly released to CPAN with less frequency then > net-snmp releases) > > 3) users may want up upgrade either a perl module or libsnmp without changing > the other (though not recommended - users will want this flexibility where > possible) > > so how about this as versioning scheme > > perl module version number will, by release policy, match the net-snmp package > version number for major and minor release, but be allowed to rev relatively > independently for micro-release. > > for example > > net-snmp 5.3.1 => perl SNMP 5.03 or 5.0302 or 5.0399 > > this still devotes 2 decimal places to minor rev. and the next 2 decimal > places > to track perl module micro releases. It eliminates the 3 decimal place > sub-micro > rev altogether. > > the makefile would ignore differences other than major and minor rev. Major or > minor rev. differences would elicit a complaint. > > Version munge need not touch perl module versions for micro releases unless > something has changed. on major and minor releases it would set corresponding > perl floatized version and reset the perl module micro release to zero. > > specific exceptional dependencies can always be enforced at perl runtime by > examining NetSnmpVersionInfo (properly exported). > > thoughts? > > -G > > > ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Net-snmp-coders mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
