On Mon, 24 May 2010 10:41:41 +0200 Benjamin Zores <b...@geexbox.org> said:
simple answer: no. why? because until 1.0 we are NOT maintaining ABI or API compatibility. that's what 1.0 is about. no - we will NOT change the .so major version for this as i want to STRICTLY keep so versions in line with library versions. a 2.0 == api/abi break from 1.x but until 1.0 we discard any effort in tracking abi and api changes. this saves time and effort for us and this has been the policy ever since. (if we have changed .so major versions we'd probably be at like libXXX.so.87 by now). so not going to happen. as of 1.0 compatbility will be strictly adhered to. ie 1.0 and 1.1 will be forwards compatible (apps written for 1.0 will work with 1.1 - but possibly not the other way around - eg we added a function call in 1.1 that wasn't in 1.0 - this is the standard way things work on linux/unix). as such every snapshot we added a change in soname (temporary) to make sure you can keep backwards-compat libs around. but... you'd have to stick to using snapshots only then. as such you are using SVN and .. using it comes with its inherent qualities - you're using the developers playpen stuff. it will change api, abi, break and so on and we don't go around doing all the maintenance bits just because we change an api in our svn. sorry to be the bearer of bad news - but we choose not to do that work. if you want to do it when making packages.. go ahead :) (fyi - i just added preliminary runtime and compile time version stuff to eet - this is a longer-term plan to have easy version adapting 1.0 and beyond, but until then, it's playpen stuff. the eet version stuff is up for comment and "let me know what you think" etc. - nothing in any other libs yet). > Hi, > > I'd like to ask you to consider a version number change/bump when API changes. > One of the biggest issue with EFL (my point of view but shared by > dozens people) is the > API unstability. > > As a developer, I understand and am fine with it but it's just not > right for users and distro maintainers > as one can't just always ask for using the latest SVN. > > E.g. Latest snapshot release of Elementary is 0.6.0.063. > Latest SVN still is 0.6.0.063 but the API is different: some new > functions (no problem here) but some existing proto have changed. > When developing an application, one has no way to even keep a > compatibility level as there's no way to determine which > version of the library we're compiling against. > > So I'm not requesting for any release/snapshots or whatever but if you > could just: > - update the libefl.pc > - potentially have a version number in a #define in the lib header > > Each time API/ABI has changed, that would be really helpful. > > Thx, > > Ben > > ------------------------------------------------------------------------------ > > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
