Just curious, but are you planning to have one last tag for the 1.26.x branch? I’m one of the maintainers of the gstreamer feedstock on conda-forge and was wondering if the source download directory would be updated for 1.26.x before 1.28.0 is out.
I have an open issue now on the gstreamer feedstock on whether I should open a branch to keep that current with bug fixes/improvements, at least for a while. That feedstock and other gstreamer related feedstocks currently only have a main branch. I’m getting a little pushback on that.
There are several feedstocks related to gstreamer on conda-forge. The primary one is gstreamer-feedstock, which has three recipes. One each for gstreamer, gst-plugins-base, and gst-plugins-good. There are other feedstocks for gst-plugins-[good, bad, ugly] and others that mainly follow the different subprojects.
The gst-python feedstock for a long time had been stuck at 1.24, The current maintainers just didn’t have the time to keep it current. During the US Gov shutdown, I volunteered to become a maintainer and brought gst-python up to date to 1.26 with the help of the other maintainers. I wanted to update 1.24.x with the latest bugfixes, and I found that I couldn’t because the different feedstocks only had a main branch, so only the latest version was getting built. The 1.24.x version of gstreamer and its plugins on conda-forge is stuck at 1.24.11, but I’d like to not have that happen to the 1.26 branch.
This is precisely how you get stuck at 1.24.11 once more.
Although the timeframe is unclear, it is true that “we’ll keep fixing 1.26 after 1.28” for GStreamer. Waiting on upstream tags is dangerous from a conda-forge perspective. The safest way is to utilize a temporary 1.26.x maintenance branch in the feedstock; it has little churn, primarily backports and build fixes, and keeps users intact.
You drop 1.26 as soon as it is evidently EOL upstream. Since everything resides on `main`, it is far preferable to freezing a full stack.