[Clam-devel] 1.3 release?

[Pau Arumí]

On dv, 2008-08-01 at 18:35 +0200, David García Garzón wrote:
> I just bumped the version in CHANGES to 1.3, and also changed the way of 
> computing the library soname in linux so it takes also the minor version.
> Libname: libclamcore.1.3.0.so libclamcore.13.0.so
> Soname: libclamcore.1.so libclamcore.13.so
> Linkername: libclamcore.so libclamcore.so (same)
> 
> Notice that this have produced some problems before with development 
> sandboxes. Just to be sure, remove all the generated libraries 
> (.so, .dylib, .dll or .lib) on scons/libs/*/ and in the installation folder

For the record: the upgrade worked fine here without removing old files.
(I will clean the old dead links anyway)

BTW, I like the new versioning scheme. But what is the reason for
changing ?

before  
libclam.so.1, libclam.so.1.2,  libclam.so.1.2.1
now
libclam.so.13, libclam.so.13,0

Personal taste? Debian policy?...

Commited NE/CHANGES version 1.3.0 to match the libs

P

> Extra culture on linux libs follows
> 
> ==================
> 
> (to disambiguate 'link': fs-link is a filesytem link, an alias, while link is 
> the build step)
> 
> Libname is the actual library file generated, it includes the full version 
> numbering in the name. Having versioned names on the libraries allows having 
> programs that run with different versions of the library in the same system.
> 
> Linker name is the name you provide to the compiler to build the binary. It is 
> a fs-link pointing to the current version libname. Having a linker name 
> allows you to decouple your build system from the actual library version you 
> are linking to.
> 
> Soname is the name that executables uses to look for the library on run-time. 
> That name is embeded in the libraries when they are created and the linker 
> looks for it and stores it on the executable in order to look for it in 
> run-time using a fs-link pointing to the actual libname. Why a soname 
> different than the libname? The idea is that if you have to do bugfixes that 
> doesn't change the ABI of the library we can do a 1.3.1 version, fs-link 
> libclamcore.13.so to libclamcore.13.1.so and all previously compiled binaries 
> will work with the fixed version without recompiling them because they look 
> for the soname.
> 
> So, you build a binary specifying the linkername of the library to link with. 
> The linker looks for the library which is a fs-link to the actual libraryname 
> and stores the soname in the new binary for later use. When running the 
> binary, the runtime library loader looks for the soname
> 
> Thus, in most linux distros, binary dependencies and conflicts are set among 
> sonames, not versions because same soname is meant to be compatible. Build 
> dependencies are set usually to linkernames unless you have to restrict it to 
> allow the same package to be rebuilt with a newer version of the library 
> without any change.
> 
> 
> El Friday 01 August 2008 13:35:04 David García Garzón va escriure:
> > I was thinking on proposing it. Those changes you mention are very likely
> > to introduce new bugs or turning the framework unstable for a while and,
> > yes is worth to do a release before that. I think i can get it done next
> > week with some little help of the GSoC students, Hernan and the scripts.
> >
> > Let me this weekend to propose a release plan. i would like to ask GSoC
> > students just to have their work in a minimum release status, so please
> > send it current status and release goals, answering this thread. Some
> > concrete comments:
> > - Pawel: I think Turnaround is not functional at this point so we won't
> > release it unless you surprise me with a mega commit
> > - Francisco: I think commited changes on TypedPorts are not intrusive, so
> > just review the migration guide. Any other consideration, or think needing
> > documentation regarding your work?
> > - Yushen/Greg: I don't know about Yushen synthetizer being in release state
> > or not and whether it affects to the realeaseability of Greg's one. Please
> > report on this thread.
> > - Natanael, is faust releasable? are the flags to include them or not the
> > proper ones? Could you do some wiki walk through on network editor features
> > we could link for the release announcement? It would be nice if you
> > concentrate on stabilizing current features.
> > - Jun, we should stabilize current features and document how to do an
> > aggregation extractor on it's current form. I will also help you to update
> > the packaging as we have now some dependencies on python we didn't have and
> > new files to install.
> > - To all: We should update the CHANGES files of the packages we modified.
> > Feel free to edit them. Keep in mind that, as opposite to commit logs which
> > are addressed to CLAM developers, the CHANGES files are addressed to users.
> > Users of CLAM lib are developers using CLAM. But users of the applications
> > (NetworkEditor...) are just final users. So write down the changes that are
> > relevant to each audience.
> > - David: I should disable some unfinished features such as the Jack tab and
> > polish the new ones (LADSPA).
> > - Hernan, what about the python bindings? are they release ready? Could we
> > add a PyQT frontend to the application template scripts?
> >
> > Please, answer to this thread with you comments.
> >
> > David.
> >
> > El Friday 01 August 2008 12:07:42 Pau Arumí va escriure:
> > > What do you think?
> > >
> > > Many new features are ready. And maybe releasing before the heavy
> > > changes on hierarchical-networks and typed-controls, is better.
> > > Unfortunately I don't have much time to offer before September...
> > >
> > > P
> > >
> > >
> > > _______________________________________________
> > > Clam-devel mailing list
> > > Clam-devel at llistes.projectes.lafarga.org
> > > https://llistes.projectes.lafarga.org/cgi-bin/mailman/listinfo/clam-devel
> 
>