https://wiki.gnome.org/Projects/Vala reads "Current Stable" for 0.44.3. It would be nice to have it in gentoo (rather than gnome-next) and vala.eclass already reads "VALA_MAX_API_VERSION=${VALA_MAX_API_VERSION:-0.44}". Thanks!
PS: I was actually brought here by repoman: dependency.unknown 7 media-libs/gegl/gegl-0.3.0.ebuild: DEPEND: dev-lang/vala:0.44[vapigen(+)] media-libs/gegl/gegl-0.3.0-r1.ebuild: DEPEND: dev-lang/vala:0.44[vapigen(+)] media-libs/gegl/gegl-0.3.26.ebuild: DEPEND: dev-lang/vala:0.44[vapigen(+)] media-libs/gegl/gegl-0.3.34.ebuild: DEPEND: dev-lang/vala:0.44[vapigen(+)] media-libs/gegl/gegl-0.4.14.ebuild: DEPEND: dev-lang/vala:0.44[vapigen(+)] media-libs/gegl/gegl-0.4.16.ebuild: DEPEND: dev-lang/vala:0.44[vapigen(+)] media-libs/gegl/gegl-9999.ebuild: DEPEND: dev-lang/vala:0.44[vapigen(+)]
fwiw, it's VALA_MAX_API_VERSION=0.44 in there precisely for the benefit of gnome-next(sic) and other overlays - otherwise they'd need to copy all vala inheriting ebuilds just to get them to build with 0.44 as a choice too (and apparently for some reason feel strongly about having only the latest vala installed, not multiple slots, though it's good to test)
Oh, and You can safely ignore that dependency.unknown as far as I'm concerned. I'm not sure how to change things in the eclass to make repoman happy; I consider it a false positive. Yes, adding 0.44 to the main tree will temporarily "fix" it, but as soon as 0.45 dev releases start coming out, the MAX will be bumped in the eclass and it'll start complaining about 0.46 instead. The only way to avoid repoman complaining is being able to keep up with the release cycles AND packaging early development releases in main tree too. We are not there yet with GNOME team manpower catchup, or manpower period, thus meanwhile we try to not block others doing this work in their overlays.
I see. I had a closer look at the vala eclass again: I don't see a way to fix vala_depend without a function to check "does package X have slot Y" which seems slow to run and tricky to implement. Shall we close this ticket?
I don't think such checks can really look into vala SLOTs provided by other repos (overlays). And that's the whole reason it throws a dependency.unknown - if we didn't support other repos again, we could simply adjust VALA_MAX_API_VERSION default back to 0.42 (and skip any interim already removed release cycle slots like it currently already does for 0.38), but that defeats the whole purpose. Technically it's still a lacking version bump regardless, so that bug may remain as that, the rest was just an explanatory detour to the repoman comments.
+1, sounds good
commit 3d21434377c899a88314572b42fd8c81e607c72e Author: Mart Raudsepp <leio@gentoo.org> Date: Sat Jul 27 22:46:06 2019 +0300 dev-lang/vala: bump to 0.44.6
