On Thu, 2 Feb 2012 at 19:24:32 +0100, Andreas Metzler wrote: > Carlos R. Mafra <[email protected]> wrote: > > On Wed, 1 Feb 2012 at 20:32:04 +0100, Andreas Metzler wrote: > > >> It shows that the ABI of libwutil was broken by removing a public > >> symbol. Any applications linking against libwutil using this symbol > >> will segfault when the new libwutil is installed. > > > But copy_file() was added to libwutil 2 weeks ago and renamed yesterday. > > So I guess this doesn't count as an ABI break, right? > > Hello, > It is a matter of policy. Many projects use something like: > > * We take the liberty of breaking the ABI in GIT but care about > not doing this in releases. > * There is a development branch and a relaese branch. The development > can break without notice, the release one not. > > copy_file() was included in wmaker 0.95.1.
Ok, but soon after 0.95.1 came out people actually started to test it and found some things (like 'make dist' not compiling etc). So there are a few essential fixes on top of 0.95.1 (which should have been caught before, but that's how things are), and that should be the stable thing. > I would recommend to revert the function rename. If not, it would be > very kind to distributors to push a 0.95.2 with only the > rename change. The function name must be kept non-generic to avoid conflicts, in this case wmakerconf had a copy_file() function which clashed. So it was a stupid mistake I did to name something copy_file() in the lib, wcopy_file() should be ok. What can be done is to have one or two weeks where people _test_ things and then we release 0.95.2. We need to have any remaining library issue sorted out. Sometime ago somebody made a patch to the WINGs NEWS file explaining what had changed etc, that was a good thing. -- To unsubscribe, send mail to [email protected].
