Re: [Vala] backwards compatibility



On Mon, 2014-10-27 at 12:00 +0000, Patrick Welche wrote:
On Mon, Oct 27, 2014 at 09:31:07AM +0100, Luca Bruno wrote:
On 27/10/2014 09:08, Patrick Welche wrote:
I'm new to vala and am wondering what compatibility between versions is
like, e.g., should I expect to be able to use a recent 0.26.1 compiler
to compile code from the days of 0.12?
You must expect every new stable release to be incompatible with the
previous. Either because of a compiler change, or because of bindings
breakage. That said, it's not that we break at every new stable release,
only when we feel it's best to break instead of keeping old obsolete things.

Do you have a rule of thumb on how likely a breakage is / what to look
for in NEWS?

Incompatibilities in the language/compiler should be rare. An example of
a recent problem is that the compiler didn't check the name of
destructors at all. This was a clear bug in the compiler, however, the
bug fix broke the build of a few projects because they accidentally used
incorrect destructor names. This was easy to fix, though, and the fixed
Vala applications/libraries now build fine with older and newer versions
of the compiler.

Bindings are not quite as stable, unfortunately. We try to keep backward
compatibility there as well, as far as possible. However, sometimes we
have to introduce breaking changes to fix an issue.

If a package, rather than testing for features (what are the sort of
features one could test for in vala?), feeds e.g., vala>= 0.20 to
pkg_check_modules, then one has to keep a copy of vala-0.20 around,
and so on for all the various vala using packages?

Well-maintained packages are expected to always build with the latest
stable Vala version. For packages that haven't been updated in a while,
I would still recommend to first try to build with the latest stable
Vala version. Depending on the age of the package, it should just work
in most cases or require only small changes. Where necessary, `#if
VALA_0_XY` can be used to support multiple Vala versions in a single
code base.

Yet a single glib and a single copy of gcc will do for other packages?

Updates for both, glib and gcc, have broken other packages in the past.
gcc probably much more than glib. Developers of glib and gcc try to
avoid such issues just as we do, but sometimes a breaking change is
considered worth the trouble.

If you encounter an issue where you believe the incompatibility is a
mistake, please report it to bugzilla.

Regards,
Jürg



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]