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 _______________________________________________ vala-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/vala-list
