On Fri, 3 Jun 2016 14:27:38 +0100 Emil Velikov <[email protected]> wrote:
> From: Emil Velikov <[email protected]> > > --- > 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
pgpwxYC7N0E9P.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
