On Sun, Jul 25, 2010 at 11:49:35AM +0200, Jose Carlos Garcia Sogo wrote: > On Sun, Jul 25, 2010 at 11:38 AM, Chris Frey <cdf...@foursquare.net> wrote: > > On Sun, Jul 25, 2010 at 11:11:55AM +0200, Jose Carlos Garcia Sogo wrote: > >> If there is an API change, first the soname of the library should be > >> bumped (that's upstream labor) so the package should move from > >> libbarry0 to libbarry1. > > > > Yes, this is the way it will be done once we release a version 1.0. > > But until then, the 0.x version stream of Barry is considered "development" > > and the API can and does change at will, with no soname version changes. > > > > See doc/VersionNotes for the plan for verion 1.0, when that day comes. > > Ok, but the main problem is that usually a lot of people use the > software long before that 1.0 version is released, and reaching to it > takes ages, so not changing soname makes packaging much more > difficult.
I know. But nearly all Barry releases so far have changed the API in some small way; so the package should be, perhaps, libbarry16 by now. If you wish to package Barry that way, I don't mind. Please do. I'm just trying to make clear that API breakages are to be expected, and I'm not ready to invest a lot of time in preserving backward compatibility when we haven't reached version 1.0 yet. If people are installing version 0.16 of the library, it makes sense to install 0.16 utils as well. The PPA packages should be setup in such a way as to encourage that lockstep. So I (or somebody) need to double check the default Barry package rules shortly. - Chris ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first _______________________________________________ Barry-devel mailing list Barry-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/barry-devel
