[Clam-devel] 1.3 release?

[David García Garzón]

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


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