+1. Thanks very much Jody. Great work. My one suggestion relates to backporting fixes to stable and maintenance. In my view, you are correct to note that failing to backport fixes makes these branches redundant, but then so does immediately backporting all changes as this makes the branches identical.
I know of several instances in which developers immediately backported fixes that broke all three branches, sometimes without even building on non-master branches. My understanding is that stable and maintenance are meant to provide users with increasing insulation from change, and I think these call for a bit more developer caution. While simple or urgent fixes (e.g. vulnerabilities, null checks, some one liners) can or even must be backported immediately, I encourage developers to prove their less urgent or more complex fixes on master for a few days to a week before backporting. Can we include something to this effect in the guide? Kind regards, Ben. On 26/06/15 08:17, Jody Garnett wrote: > Clarification on our expectations for submitting fixes to master / stable > / maintenance -- Ben Caradoc-Davies <[email protected]> -- Ben Caradoc-Davies <[email protected]> Director Transient Software Limited <http://transient.nz/> New Zealand ------------------------------------------------------------------------------ Monitor 25 network devices or servers for free with OpManager! OpManager is web-based network management software that monitors network devices and physical & virtual servers, alerts via email & sms for fault. Monitor 25 devices for free with no restriction. Download now http://ad.doubleclick.net/ddm/clk/292181274;119417398;o _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
