On 18 Aug 2014, at 14.22, Valentin V. Bartenev <vbart@nginx.com> wrote:

> On Monday 18 August 2014 13:45:46 Jason Woods wrote:
> [..]
>> There's the fear there are significant changes from 1.6 to 1.7 that may
>> introduce other problems, and would need to go through some extensive
>> testing before we can commit. Especially as the 1.6 is labelled "stable" and
>> the 1.7 "mainline" (and not stable) - maybe these terms aren't meant to
>> convey the meaning they appear to though. I'll start discussion about
>> testing 1.7 though.
> [..]
>
> It's a common misunderstanding about branches.
> Check this out: http://nginx.com/blog/nginx-1-6-1-7-released/
>
> In most cases the only care you need with the mainline branch is to read the
> changelog before update.
>
> Also you can consider to buy nginx plus license to get the official support
> and thus feel yourself more confident.
>
> wbr, Valentin V. Bartenev

Thanks, that's a perfect explanation.

The fear remains though that to fix a single small issue that is possibly a few lines changed, I would be (in essence) changing thousands upon thousands of lines, adding new features, updating features, and creating a much larger surface area for potential new bugs. Where sticking with the stable feature branch gives us what the stable feature branch is intended to do - minimise change and surface area for new issues.

Reading the changelog I agree is the best approach, but if a new feature is added and it modified shared-code to support it, this might not always included in a change log. Plus some shared code, even if mentioned, unless I'm an Nginx developer likely won't know what other parts it affects. And the moment something critical is changed and fully described in the changelog (because mainline has updates to existing features) then we hit the blocker where we need to weigh up risk again - upgrade with potential for problem but benefit from bug fixes, or stick to current version and take the risk of not having bug fixes. I believe this is the reason the stable branch exists, and I'm grateful for it.

I guess I could brew my own version with the patch. Unfortunately, I don't have resource to add package management to the list to ensure we keep up to date with bug fixes since we'll be leaving the nginx provided repositories (great btw! thanks). It's something I will have to weigh up though, thanks for the suggestion.

Thanks for all the input. I guess the only question now, outside of philosophical discussions of risk, is whether Nginx team treat this issue as a "major bug fix". Hopefully they do and we'll get the fix soon in the stable branch. If not, I'll keep testing 1.7.x with the view to move to it soon. And we'll just flow into 1.8 which will be the next stable feature branch if the product release schedule remains the same :-)

Thank you again, and if the Nginx devs/contributors are reading this, keep up the good work!

Jason
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx