Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by krbdev.mit.edu (8.9.3p2) with ESMTP id TAA29394; Mon, 5 Jun 2006 19:21:46 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id k55NLjd7027673; Mon, 5 Jun 2006 19:21:46 -0400 (EDT) Received: from [18.18.1.160] (NOME-KING.MIT.EDU [18.18.1.160]) (authenticated bits=0) (User authenticated as raeburn@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id k55NLcI5005608 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Mon, 5 Jun 2006 19:21:38 -0400 (EDT) In-Reply-To: References: MIME-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ken Raeburn Subject: Re: [krbdev.mit.edu #3821] krb5-1.5 alpha - should library version numbers be bumped? Date: Mon, 5 Jun 2006 19:21:53 -0400 To: MIT Kerberos RT X-Mailer: Apple Mail (2.750) X-Spam-Score: 1.217 X-Spam-Level: * (1.217) X-Spam-Flag: NO X-Scanned-BY: MIMEDefang 2.42 RT-Send-Cc: X-RT-Original-Encoding: us-ascii Content-Length: 1367 On May 31, 2006, at 10:51, Ezra Peisach via RT wrote: > Should the library versions be bimped on the shared libraries? > > With the plugin architecture - I suspect that we will have > compatibility > problems on at least libkdb5... The export lists between the old and > current library versions are very different.... Hm, yeah, I should check on that... > The gssrpc library has changed - functions have gssrpc_.... > prepended - > so the libraries are definitly incompatible... A 1.4 source tree I'm looking at has gssrpc_ on all the names in the export list. What old version are you looking at? > The krb5 library no longer has gmt_mktime, krb5_free_ets, > krb5_free_uio, > krb5_init_ets, krb5_setenv, krb5_unsetenv.... The krb5_init_ets might > break really old code... > > The k5crypto has lost krb5_random2key > > libcomerr has lost add_to_error_table, free_error_table, > init_error_table, initialize_error_table_r... - but I think we are > ok... I think these have been considered internal interfaces for some time, so their disappearance just means we're tightening up. We decided a while back that we only cared about the symbols in the public API -- we'll redefine, hide, or delete private symbols without changing the major version number, and just assume the libraries and MIT's programs will be from the same release. Ken