Release schedule and stable releases

[Cong Wang]

On Fri, Mar 13, 2015 at 3:44 AM, Thomas Haller <thaller at redhat.com> wrote:
> On Thu, 2015-03-12 at 11:52 -0700, Cong Wang wrote:
>> Hi, Thomas
>
> Hi Cong,
>
>
>> What is your schedule for the 3.2.26 release? We are waiting for it as
>> we need some new API's. :)
>
> Last week I sent out 3.2.26-rc1. Only wait whether an issue shows up.
> Usually ~2 weeks for -rc1.


OK.

>
>
>> Also, there seems no stable release like 3.2.25.x? Commits like
>> "idiag: fix out of bound error parsing idiag messages" really deserves
>> a stable release, since there are more than 6 months between 3.2.25
>> and 3.2.26 releases.
>
> libnl3 never had minor releases... I think what is a good way to manage
> releases for large projects (e.g. for the kernel), is not necessarily
> best for libnl3.
>
>
> I will do more often major releases whenever something important shows
> up or when somebody here asks me for a new release (*hint*).
>
>
> For a downstream package maintainer it's hard to asses which patches
> should be backported. A minor release would highlight that there is
> something important/new.
> But instead, I added a git-note refs/notes/release-notes to highlight
> important patches that should be backported.


The problem with this is that different package maintainers have
different versions, it is hard for library users to check the minimum
version of libnl to ensure it is complied against on a non-buggy libnl.

Say Mesos needs a bug fix merged between 3.2.25 and 3.2.26
in upstream, some distro backports it to its 3.2.25.3, another one
backports it to its 3.2.25.4, which version should Mesos check to
ensure it is not compiled against a buggy libnl? :)


>
> I will mark commits there (for the future). When new important patches show up,
> I will send an email to the mailing list to notify downstream package maintainers
> that there is something to backport.
>
> Only question is, which commits should be marked as "backport". But that
> problem is largely the same as which commits to cherry-pick for
> backporting. Pointer from anybody welcome.
>
>
> how does that sound?
>

I don't worry about backporting patches, at very least we can backport
by ourselves. The problem is the version number, we need an upstream
version which works for all distros.

Thanks.