This Confluence has been LDAP enabled, if you are an ASF Committer, please use your LDAP Credentials to login. Any problems file an INFRA jira ticket please.

Page tree
Skip to end of metadata
Go to start of metadata

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
  2. Establish rules for what can go into later maintenance levels of a release
  3. 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.
  4. 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.
  • No labels