Weston versioning (Re: [PATCH weston 6/6] libweston: do not use weston version in libweston.pc)

[Jan Engelhardt]

On Friday 2016-07-15 15:30, Pekka Paalanen wrote:
>> >OTOH, would adding a new libweston MAJOR in an already stable and
>> >released binary distribution be absolutely forbidden? It would by
>> >definition not affect anything the distribution was released with,
>> >unless libweston's dependencies changed, but I think the
>> >dependencies might change less often than we bump MAJOR.  
>> 
>> What the distro permits is a matter of their policy. Nothing you
>> should be concerned about, because what you do is just regularly
>> releasing new versions of your software.
>
>That's true about policy, yes, but I'm getting a strange vibe here.
>You too seem to advocate ignoring distributions rather than taking
>them into account. [...]
>This is the second time I have been turned down for trying
>to figure out what distributions would like to have from the
>upstream.

Well let me rephrase it then. In openSUSE, adding a package to the
update channel (bugfix channel) is possible, as is doing so with new
SONAME, as we support selectively rebuilding packages (already have
to do that because of the kernel's unstability guarantee).

But I probably would not normally ship a new shiny libweston with new
features and new APIs in the bugfix channel, so whatever new release
may be available at freedesktop.org, it would have to wait for the
next distro release.

So it's not really a turn-down, but I just do not have anything
to request from upstream with regard to releases.


>The earlier time was when I though that avoiding circular
>dependencies between projects/packages was a good thing, and I got
>told "why would you even care about that, distributions can deal
>with it". (Not by anyone on this thread.)

There are so many upstreams, not all of which are welcoming changes
proposed that would benefit distros (mixture of don't know how to
implement, don't know how to maintain if implemented, don't care, or
not-interested). Then all we can do is workaround at the distro
level, especially if the package is essential. Think util-linux
which, in fully populated mode, has a cycle with systemd, which we
had to end by building it multiple times as things become
available. Not sure whatelse to have done there.