[Libwebsockets] Release policy [was] 答复: A question about libwebsockets dns resolve and newest tag

Andy Green andy at warmcat.com
Wed May 6 14:11:13 CEST 2020

On 5/6/20 10:34 AM, Jaco Kroon wrote:
> Hi Andy,
> On 2020/04/29 12:37, Andy Green wrote:
>>> And we need a newest tag for tracing to the source;.Can you help us to
>> The situation with stable tags isn't really pleasing anyone, I think
>> they're redundant, since the commit has the same hash tagged or not
>> you can just use that unambiguously, but at any given time people who
>> believe the ordinal in tags has some magic meaning are waiting for
>> vx.y.(z + 1) and missing out on patches already on the -stable branch.
>> I looked at openembedded the other day and while their lws recipe is
>> pretty up-to-date, it's on 4.0.1 and the patch updating it was only a
>> couple of days old at the time I looked.  But as of a week ago, there
>> are 25 backported patches ahead of that on v4.0-stable openembedded
>> users are not getting the benefit of yet, presumably because they
>> didn't see v4.0.2+++ tagged out.
> I didn't either, nor any of the releases since then, now at 4.0.7 - but
> that could be >=4.0.8 as of writing of this email.  And I'm hoping that
> those who pushed you to this insane release schedule is reading this.

This just seems to be how it's playing out, it's not about anyone 
forcing anything.  The backport patches are almost all fixes... a good 
proportion of them are coming from somebody reporting a problem, when 
it's fixed and there's a patch on -stable for it, it seems a lot of 
users feel they can't consume it without some specific tagged version 
that has the fix.  So it pushes towards this situation everything wants 
a tag.  Although, plus or minus the extra CMake version change, it's the 
same whether it is tagged or just available on -stable.

It's not just users there are other distro maintainers that have gotten 
upset that stuff is on -stable "without a point release".

>> The problem is there isn't any real logic for when to make a new tag,
>> for any particular patch if it fixes what you care about you would
>> naturally think that should be cause for a tag.  It leads to tagging
>> every commit - this is the approach for kernel stable tree - which is
>> more work for me just to stop the tag-belivers using
>> broken-but-already-fixed code.
>> I think I probably have to give up and move to tagging every stable
>> commit to stop these kind of requests coming and get people to use the
>> latest stuff.  It's messy because CMakeLists.txt wants its version
>> updating accordingly each time.
> I agree with much of what you say here.  But I also think that releasing
> a new version on every single commit is somewhat over the top.  Create a
> policy and stick with that.  If others disagree, they can back port
> those specific patches if they really need it that quickly.

It's not a huge problem, it's really somehow about regenerating an 
svn-style monotonic ordinal that people want to see.

Usually after a few months backports die down, partly because there less 
broken things and partly because master has deviated so much cleanups 
and refactors and even fixes can't be backported without a huge effort.

> In spite of what you say, no, kernel stable doesn't quite do that for
> every commit any more.  This was seemingly the case at some point where
> the policy was seemingly "we only back-port security fixes", or more to
> the point, minor fixes currently will batch up, but major (security,
> permanent data corruption, and others) fixes will trigger a release.
> But minor fixes also won't batch up indefinitely.

Right... they do batch them up.  But the volume of tags is typically > 
100 on a release, on the biggest stable branch v3.1-stable we reached 
110 patches ahead of v3.1.0.  So the approach of generating >100 tags 
per stable branch is the same.

> What seems to be the most sensible reasoning, but not always practical,
> so you need to make the call here, is to define a branch to have a
> specific set of features.  New features are added on master, but not the
> stable branch(es).  Bug fixes are back-ported.  And then released
> according to some schedule.  If there are critical fixes that need to
> bypass this normal they'll backport and do z+1, eg, security.

That is the case, the rule is that -stable can't take anything that 
breaks the abi.


So if a distro has things built against libwebsockets.so.16, stable 
updates to the package that still builds to libwebsockets.so.16 
shouldn't need to trigger rebuilds of packages that depend on that.

The amount of backports might seem large but actually it's like 35% of 
the patches on master since v4.0.0

$ git log --oneline v4.0.0..master | wc -l
$ git log --oneline v4.0.0..v4.0-stable | wc -l

> Using asterisk as example, since that's what I'm mostly working on
> currently, there are active branches 13, 16, 17 and master.  13 and 16
> are defined to be LTS (aka long term support, for what that's worth).
> So all bug fixes goes into all of these.  As soon as 18 gets released,
> 17 will go into "security only" mode for a short while, can't remember
> exactly how long.  So for each of 13, 16 and 17 new tags gets released
> on the minor version with whatever code changes/improvements has been
> committed into the respective branches (eg, 13.32.0 => 13.33.0).  If at
> any point in that cycle a really crazy bug (security - according to
> whatever your definition is) would trigger bugfix release, eg, 13.32.1,
> and even then, a call would be made "can we pull forward the 13.33.0
> release, are things adequately stable and are we not messing with the
> release schedule too much?"

It's similar here, occasionally I will backport fixes to earlier trees 
if it seems important... it's spelled out in the release policy document 

> glusterfs has a similar policy with respect to their release schedule.
> If your policy is "release on every commit", so be it.  But as a
> packager there is no way to keep up with that, so I'm on the opposite
> side of the fence, if there is a bug that worries me enough that I can't
> wait 3 or 4 weeks, I'll back-port that single patch.

Hm well, as I say there are reasons for moving to this.  For most people 
who want their fix, their fix is definitely reason for a stable point 

> I have no idea what your criteria is for incrementing major versions, or
> minors, but would you mind publishing a policy somewhere?  Perhaps as a
> packager I then simply end up tracking major.minor and not
> major.minor.bugfix unless some user complains that they need specific
> bugfix release, and you then just more regularly bump the minor, say
> monthly or bi-weekly?
> I'm fairly certain that something like:
> * major versions are reserved for feature development or major reworks
> and will be released as and when ready.
> * minor versions will be released as needed, but at most bi-weekly, but
> no longer than four weeks after the first commit to the major version
> from release of the previous minor version
> * bugfix releases will be made on each and every bugfix commit, but at
> most once a day unless under extraordinary circumstances.
> Should work fairly well for everyone.  But this would not be my
> recommendation to you, I'd reserve bugfix releases for "major" bugs
> and/or security fixes.

Major versions are coming when it makes sense for various reasons... I 
think it took too long from v3.2 to v4.0.  But for example the current 
focus is shift everything over to double down on CMake, CTest and CPack 
and Sai CI.  When that's got the kinks ironed out and move to expanding 
the number of CTest tests, I think that's a good trigger for v4.1.

I don't know how to codify that or what the advantage would be if I 
did... sometimes like on v4.0 I have nonpublic stuff in the pipeline 
too... it just has to wait for the right time.

> Those of us that package could then track minor versions, and use
> bug-fix releases if needed (ie, we have a user with that specific
> issue).  Those that really need the bugfix releases can use those.
> On the other hand, as I've stated, people honestly can just back-port
> their own specific patches, or checkout the specific commit that they
> need that includes the bug that annoys them (as you've stated, heck
> github makes that very easy since you can download a tar.gz of a
> specific commit).

They can, but as master diverges, that becomes impractical for normal 
mortals.  The answer is maintain the last stable for fixes and try not 
to wait so long between major releases next time.

> As a packager, if you don't release a bugfix on every commit, I'm quite
> happy to download a specific commit as a patch and apply that
> specifically to the previously released tag.  Which is the approach I
> take with asterisk if it's really that urgent (of which I've had
> probably 3 or 4 in the last few years).  Waiting for a next release is
> generally just fine.  Very few things in life really needs that commit
> *right now*.  And if someone claim that - well, then they should be
> willing to do the work and not put it (completely) on you.

This is something that maintainer has to do, it's not just OP this has 
been a thing for a while.  So let's see what happens if there is always 
a tag for whatever is backported.

> As a packager a policy to decide how to best approach the task of
> packaging, and how to track upstream - in this case you - would be
> greatly appreciated.

Well, how to track it is the -stable branch... tags or not it's the same 
thing underneath.  Objectively sometimes something "bad" is fixed and 
that's a good reason to trigger a package update, but subjectively 
someone somewhere thinks each of the fixes was important enough for a 
tag at least.

Neither that not pushing things on -stable and letting them pile up are 
very satisfying from a "how do I know if I need to repackage" POV... 
that decision is also partly based on the distro's approach.

Something else, what's your opinion about CPack?  In the last days I 
added artifact support to Sai and at least in the "distro-recommended" 
build it now produces .deb / .rpm packages.  Does this have any legs in 
terms of helping / aligning with your distro packaging?


More information about the Libwebsockets mailing list