New release numbering scheme and Git branches

We'd like to propose a change to the release numbering and Git branching
before the next release.  The idea is to (re)introduce a "maint" branch
that only gets obvious bug fixes, and to also cut releases from that.
We would keep the X.Y.Z version numbers, and increment Z for bug fix
releases (cut from "maint"), increment Y for backwards-compatible
feature releases (cut from "master"), and increment X when releasing
backwards-incompatible features.  We'd also like to introduce a "pu"
branch for merging pull requests _before_ reviewing them closely.

That's basically what the gitworkflows(7) man page suggests.  My hope is
that we could get out minor releases (with possibly just a small number
of fixes) more often, as other projects do it.  The "pu" branch would
make new contributions more accessible for testing.

So, unless anybody objects, the next release will be version 1.5, and
we'll then create the "maint" and "pu" branches.

Holger

------------------------------------------------------------------------------
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead. 
Download for free and get started troubleshooting in minutes. 
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
_______________________________________________________
Nagios Plugin Development Mailing List Nagiosplug-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Unsubscribe at https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel
::: Please include plugins version (-v) and OS when reporting any issue. 
::: Messages without supporting info will risk being sent to /dev/null