Re: [mosquitto-dev] Version 1.6 released

[Tatsuzo Osawa <tatsuzo.osawa@xxxxxxxxx>]

Hi Greg,

Thank you for your precious feedback.

Sorry I don't answer your point one by one, but I'd like to answer as
followings:

1) I've agreed with Mosquitto is just an open source project which has
no guarantee. I said it on this mail loop. So this policy can be kept
under the best effort.

2) I believe the workload which I recommended is almost as same as the
existing. We can minimize it by providing only source files (no
packaging) and restricting the support only security patches and the
critical (crash etc.) issues for the previous version. I can
contribute if necessary.

3) Regarding develop and main branches, I know many open sources
provide separated release policy, e.g. the even number of minor
versions are stable releases and the odd are develop releases. But It
is just a naming issue, so I recommended the way which does not change
the existing.

4) Regarding the frequency of new main releases, the reason I'd like
to keep the period of support for each release. Providing new main
releases at most once a year makes the support period at least two
years. Actually, it took three years from v1.4 to v1.5, and almost one
year from v1.5 to v1.6. Therefore, I believe this policy is
reasonable.

Cheers,
Tatsuzo

2019年4月27日(土) 9:45 Greg Troxel <gdt@xxxxxxxxxx>:
>
> Tatsuzo Osawa <tatsuzo.osawa@xxxxxxxxx> writes:
>
> > I propose the following support policy.
> > - Provide critical bug fixes and security patches for the one previous
> > version of the main release.
>
> I guess a big question is who is a volunteer and who is being paid to
> work on mosquitto, with what agenda.  You are proposing that work be
> done, but I don't see how that leads to someone getting paid, or
> choosing to do it because it is fun.
>
> > - Minor feature updates are provided only on the develop branch, and
> > the main branch provides only bug fixes and security patches.
>
> I find "develop" and "main" to be confusing words, and they seem to line
> up with a world view that git master is a release stable branch, instead
> of where development takes place.  That's what mosquitto is doing but
> policy should be about releases, not branches in git.
>
> FWIW I don't like this branch rule, because the history is hard to
> follow.  I like having regular development on master, and release-x.y
> branches from which various x.y.z are tagged.  This is easy to
> understand even years later.  But that's not that important, and not all
> that relevant to what you are proposing.
>
> Perhaps you mean:
>
>   Micro subsequent releases provide only bug fixes and security fixes.
>
>   New minor or major releases may have more changes than micro releases.
>
> > - The feature updated main release will be provided at most once a
> > year. It is great if it can be provided almost at the same time of
> > each year.
>
> I don't know where this comes from, and I would not be in favor of such
> a rule.  A non-micro release seems appropriate when it is appropriate.
> 12 of them a year is probably crazy, as is one every other year.
> Anywhere from 1-4 times per year seems eminently reasonable.
>
> > That is, compared to the current situation, added following.
> > - Provide critical bug fixes and security patches on v1.5 for at least
> > one more year.
>
> I guess there's a governance question of who can volunteer and how they
> are given write permission to do the work.
>
> > - Provide every feature updates on develop branch. (in order to faster
> > stabilization on main branch)
>
> This seems normal, almost defatult.
>
> > I've looked at some open source support policies, and found this
> > policy I recommended seems almost standard. Regarding OpenSSL, it has
> > very conservative policy that every main releases are supported in two
> > years, and in addition some LTS (Long term support) releases are
> > supported in five years.
>
> Somebody is paying for that.  Do you know who, and can you get them to
> pay for the same thing in mosquitto?  :-)