On 2011-05-21 Jonathan Nieder wrote: > All else being equal, I'd prefer to allow testers to try > > 1. update liblzma > 2. update xz > > without breaking xz in the window between steps 1 and 2, except in > the obvious case when a function that turned out to be a bad idea > was changed or removed.
It will work between stable releases, but I wouldn't like to make such a promise for alpha releases. Maybe I could promise it for beta versions, but I'm not sure yet. Since it is likely that in some alpha-to-alpha upgrades your wish wouldn't work, I think it is simpler and safer to just assume that new things in development releases aren't stable. So with non-stable releases, keep xz and liblzma always in sync. I'm not sure if distros should ship alpha or beta versions of *shared* liblzma at all. > That would mean that even after the alpha > is over, lzma_stream_encoder_mt would stay as > > lzma_stream_encoder_mt@XZ_5.1.1alpha This made me think, what should I do when I extend old functions e.g. by adding support for a new flag? It doesn't affect backward compatibility, but it means that new applications that use the new functionality won't work with older liblzma versions. Should this kind of extensions be visible in symbol versions too, or is incrementing the minor soname enough? -- Lasse Collin | IRC: Larhzu @ IRCnet & Freenode
