Dear Wiki user, You have subscribed to a wiki page or wiki category on "Httpd Wiki" for change notification.
The "ReleaseStrategyProposal" page has been changed by EricCovener: https://wiki.apache.org/httpd/ReleaseStrategyProposal New page: = release strategy proposal = == Problems to address == * Instability of stable releases * +1: covener * Conservatively managed distributions are drifting farther and farther away from HEAD * +1: covener == Things working well == * New modules can get into users' hands pretty easily. * +1: covener * Few streams to worry about * +1: covener * Long lifecycle of a release * +1: covener == Proposal 1 == This is a WIP. Please feel free to edit if you preserve the spirit, or fork it into a new proposal if you don't. The philosophy here is to have 1 or more conservatively managed releases but to also always have 1 or more more liberally managed releases where slightly more disruptive things are tolerated. But the latter is neither trunk nor a "development" release. Some things that characterize a more conservatively managed release: * Behavior changes tend to be opt-in. * Refactoring is limited. * New function, new directives, and new modules are acceptable if their enablement doesn't put the stability of existing function at risk. * For example, mod_md on its own would have been OK, but the changes to mod_ssl to accommodate it would have needed to be (at best) guarded differently. 1. Establish a litmus test ("rules") for what can go into early maintenance levels of a release 1. Establish rules for what can go into later maintenance levels of a release 1. Establish rules for how a major.minor graduates from "early" to "late" * What does it mean for the previous 1 or 2 major.minor? * We owe special handling to 2.4 because it didn't start this way. 1. Formally document the above How this would work over time: * 2.6 is released with a few new/small things * 2.4 is stabilized * 2.6.$small continues to get the kinds of things we're doing in 2.4 today * Eventually something big comes along and we do a 2.7 or 2.8 * 2.6 is stabilized when 2.7/2.8 is released * 2.4 sticks around but maybe we pick an EOL. For 2.4, we pick it farther out then we normally would since the policy is post-GA. === Problems === * Do we need to only pick a subset of major.minor's to be eventually-LTS so we don't end up with different distributions on arbitrary major.minors? This helps cap the # of streams in service AND avoids distributions picking different ones and causing more work on all sides. --------------------------------------------------------------------- To unsubscribe, e-mail: docs-unsubscr...@httpd.apache.org For additional commands, e-mail: docs-h...@httpd.apache.org
