[RFC weston 3/4] XXX: README: Mention bits that we really want for libweston

[Pekka Paalanen]

On Fri,  3 Jun 2016 14:27:38 +0100
Emil Velikov <emil.l.velikov at gmail.com> wrote:

> From: Emil Velikov <emil.velikov at collabora.com>
> 
> ---
>  README | 12 ++++++++++++
>  1 file changed, 12 insertions(+)
> 
> diff --git a/README b/README
> index b8aa2e0..e411343 100644
> --- a/README
> +++ b/README
> @@ -161,3 +161,15 @@ major ABI-versions, except those explicitly mentioned.
>  
>  Weston's build may not sanely allow this yet, but this is the
>  intention.
> +
> +XXX: Document the versioning scheme properly
> +What breaks, what doesn't. When do we bump major, minor and patch.
> +
> +XXX: Note why should new symbols (API) be guarded by LIBWESTON_API_VERSION >= $VERSION macros.
> +
> +It allows us to add new features/API without any risk of being breaking things.
> +
> +broke when I reverted to version X" because they have explicitly requested.
> +What/how ? Simple, anyone that uses the new API explicitly annotates the verion
> +they which to use. Thus there won't be any issues of the sort "things broke
> +when I reverted to using version X-Y" as they _explicitly_ request version X ;-)

Hi,

I am confused, and I cannot even answer those questions.

The whole point of the parallel-installability to begin with is that we
don't have to care about these things until things start to settle down
and we can commit to at least some promises.

We have one number, which is shown in the library name, which we bump
every release whenever something in the ABI or API might have changed.
A program built to use one number cannot use another number, be it
smaller or greater.

We do not want to care about the risk of breaking things for a couple of
years onwards, we *will* break things randomly. Our promise is that we
bump the number on releases unless we are sure we didn't break anything
API/ABI wise.

If we talk about weston version numbers, every minor bump is a break for
libweston in the near future, signified by bumping the one number. We
also promise that there will not be need to bump the one number for
weston micro/patch version bumps, so once a 1.x stable branch is
created, libweston will be completely stable *on that branch*.

The big idea is to avoid the effort needed to prevent things breaking.
Are you suggesting we need to make that effort in any case? That is not
feasible, not at this stage.

But we also cannot wait for libweston API/ABI to mature up to such
point, because without users it will never get there. We do want to
have users, but we also need to break things at will, so this
versioning scheme is just a helping hand for users to deal with the
inevitable breakage.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 811 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20160606/6c3e2eec/attachment.sig>