----- Original Message ----- > From: "Ted Ross" <[email protected]> > To: [email protected] > Sent: Wednesday, March 22, 2017 9:43:42 AM > Subject: Qpid Dispatch Release Plans > > A couple of topics for discussion: > > Qpid Dispatch Router 0.8.0 release > ================================== > > As of now, there are 116 resolved issues queued up for 0.8.0. I'd like > to wrap up this release in the next week. I plan to defer all of the > pending features to the next release. > > If anyone has any bug fixes they would like to see included in this > release that are not already set to "Fix Version: 0.8.0", please put > them on the list. > > > Release Numbering > ================= > > I'd like to propose that the next release (after 0.8.0) be called 1.0.0. > > The x.y.z release numbering would follow the normal expectations: > > - All releases with the same 'x' shall be interoprable and we commit > to not breaking anyone's configurations as the project evolves > through a single major (x) version. > - Minor (y) releases shall be on a semi-regular cadence and shall > contain feature additions as well as rolled-up bug fixes. > - z releases shall be for bug fixes only and will be used as-needed. >
Will there be a policy for rolling upgrades? Rolling upgrade support is a pretty big deal - it's unlikely users will want to shutdown their entire dispatch network to cut from x.y.z -> x+1.y.z Would it be possible to support major number rolling upgrades across one x release? In other words, support rolling upgrades from x.y.z -> x+1.y.z but not ->x+N.y.z where N > 1? > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- -K --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
