On Wed, 15 Apr 2009, Albin Tonnerre wrote:
> Patch attached. As usual, comments are welcome in ecore, is it really necessary to have a release-info for each module ? Vincent > > Regards, > Albin > > ---------- Forwarded message ---------- > From: Carsten Haitzler <ras...@rasterman.com> > Date: Wed, Apr 15, 2009 at 3:52 AM > Subject: Re: [Proposal] release schedule and version numbering > To: Albin Tonnerre <albin.tonne...@gmail.com> > Cc: Gustavo Sverzut Barbieri <barbi...@profusion.mobi> > > > On Tue, 14 Apr 2009 18:59:40 +0200 Albin Tonnerre <albin.tonne...@gmail.com> > said: > > THIS... is why i have not wanted to release and force sonames. it totally irks > me to have "libblah 2.0" and the actual lib.so is blibblah.so.7.0 ... its > totally horrible. pre 1.0 we reserve the right to break .so's at will and we > keep our .so's at the version of the software to stop the inconsistency in > release ver, package ver and .so ver. > > if this conflicts with debian policy... then i am afraid we have a e vs debian > policy conflict and that will not be resolved until we release 1.0... > > what i might consider is renaming the libname > > instead of libevas.so.0.9.9 > libevas-pre1.so.0.9.9 > libevas-pre2.so.0.9.9 > etc. > > and on release we remove the -preXXX and go to libevas.so.1.0.0 > > thats my "compromise" :) > >> Hi, >> >> With the idea of having freezes and a release schedule, I'd really like to >> get >> proper version bumps when there are API changes in the core libraries. >> >> I know this idea hasn't been very popular in the past, mostly because the >> devs don't want to bother with this, which is something I understand. >> >> However, as you may know, I maintain the e17 packages in debian. >> Part of this job implies manually changing libraries SONAME when the >> interfaces change, which implies some patching on every single snapshot >> I'm uploading (and which breaks the interface, of course). As I'm doing >> it for debian anyway, I think I might do this is the SVN just as well, if you >> agree. >> >> What I'm doing currently is the following: use >> '-release @package_vers...@$(MINOR)' instead of >> '-version-info @version_info@', in LDFLAGS, so that the generated SONAME >> looks like the following: libevas-0.9.9.050$(MINOR).so, with MINOR being >> whatever you feel like using (I use letters, for example) >> >> The immediate benefits - besides me being happy - is that it would be easier >> to detect when users are experiencing bugs due to API changes. Imagine a >> user links an app against evas, then updates evas, which has changed SONAME: >> either he has the old evas installed and everything's fine. If he has not >> kept >> the old version, the app won't even launch as the lib will be missing, where >> he previously would have experienced crashes or random behaviour. So I >> do think that would help sometime :) >> >> Regards, >> Albin >> > > -- > Ce message a ?t? v?rifi? par MailScanner > pour des virus ou des polluriels et rien de > suspect n'a ?t? trouv?. > Message d?livr? par le serveur de messagerie de l'Universit? d'Evry. > > ------------------------------------------------------------------------------ Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
