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

Jaco Kroon jaco at uls.co.za
Wed May 6 11:34:20 CEST 2020

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.
> 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.

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.

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.

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?"

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.

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.

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).

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.

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.

Kind Regards,

More information about the Libwebsockets mailing list