Re: [Vala] development for 0.12

[pancake <pancake youterm com>]

Is there any way to check at preprocessor stage for the version of  
vala? Or I have to do this check outside (configure?) and then pass  
the -D to valac?

#ifdef VALA10
... Old/stable stuff here
#else
.. New stuff here
#endif

Thanks for the reply :)

On Oct 26, 2010, at 11:59 PM, Evan Nemerson <evan coeus-group com>  
wrote:

> On Tue, 2010-10-26 at 22:33 +0200, pancake wrote:
> > In the new versioning system of Vala many programs using libvala  
> > get broken
> > because of the internal API changes. What is the recommended way to  
> > release
> > and develop them?
>
> First off, AFAIK Jürg hasn't made any API stability promises for
> libvala... it is considered unstable, and the API will change. I'd  
> also
> like to point out that most programs written in vala don't have a
> runtime dependency on libvala and most release tarballs, including  
> Vala
> itself, don't even have a compile time dependency on valac since they
> are distributed with the C. In other words, if you are making releases
> instead of forcing people to compile from git/svn/bzr/whatever they
> don't need any version of Vala on their computer.
>
> Now, on to your question... the new versioning system should actually
> help with that because you can now have multiple instances of libvala
> installed to the same prefix at the same time. People don't need to
> choose between a stable release and an unstable release, they can have
> both.
>
> All you have to do is depend on the version of Vala that your software
> works with... 0.10 is considered to be the stable release, with the  
> 0.12
> branch (0.11.x) being unstable.
>
> > I have been working lately in gtkaml in order to add support for  
> > vala 0.12
> > and add support to the new syntax 'gtkon'. Next work will be to add  
> > 'gtkaml'
> > like 'vala' (to compile+run) and fast vapi support.
> >
> > Next release of gtkamlc will be for 0.12 only, and I would like to  
> > not
> > be limited to a single version of the compiler if the distributions  
> > does
> > not provide them.
>
> If you use features that changed between 0.10 and 0.12, that's  
> probably
> not going to happen. Like I said, libvala is unstable. You might be  
> able
> to put something together in your build system where you have two
> versions of your code (one for 0.10, one for 0.12), but that will get
> very messy very quickly.
>
> My suggestion would be to do what Vala is doing... branch your
> repository for 0.10 and continue new development against 0.12. You can
> release from the stable branch when you want to do a bugfix release
> (like vala did with 0.10.1), but most new development happens against
> the development branch which sees periodic releases as part of an
> even-numbered unstable development series.
>
> For what it's worth, Florian has said that he intends to do this with
> valadoc. I believe VTG is also doing this but I haven't confirmed it.
>
> > How are distros going to manage this? Is debian going to package  
> > vala-0.10
> > and vala-0.11 simultaneiously? Or do they will wait until 0.12 gets  
> > released?
>
> Obviously that is up to them, but they will *probably* wait for 0.12  
> to
> be released before adding it to their main repositories, although this
> will likely vary a bit from distribution to distribution.
>
> Debian might package 0.11 in experimental but keep it out of unstable
> until 0.12 is released (and likely keep 0.10 around for a while too).
> Ubuntu will probably package 0.11.x for 11.04 development but release
> with 0.12.x, especially considering the fact that they are planning on
> making Unity the default shell. Furthermore, I wouldn't be surprised  
> if
> the Vala PPA maintains both versions simultaneously for the current
> stable Ubuntu release. I think Fedora does something similar with
> rawhide.
>
> The situation is analogous to what happens for most of the rest of
> GNOME. GTK+ 2.31 is a development branch, 2.32 is stable... I think  
> the
> development series that will become 3.0 is 2.90. Examining how your
> distro of choice handles that will probably provide a good  
> indication of
> how they will handle vala development series releases.
>
> > I personally prefer to keep my programs working with the latest  
> > version of
> > the compiler, but I understand that this may break many builds if  
> > the system
> > does not have the correct compiler version.
>
> Again, the fact that two different versions are now parallel  
> installable
> should help things here, not hurt. Your program can use the  
> development
> branch while someone else uses the stable branch. Or you can use the
> current stable branch while other programs use an old stable branch.
>
> -Evan