Versions Compared

Old Version 12

changes.mady.by.user Daan

Saved on

compared with

New Version 13

changes.mady.by.user Animesh

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

As per our Releases guideline we support N-1 release for critical and security fixes. See the section Releases#SupportLifetimeofaRelease for more details Where  N is the current release being worked on and has not been officially released. If issues are found in prior release and they affect supported releases the fix should be ported in those release. It should certainly go in N and master.

If someone wants to provide fixes for prior unsupported releases they can do so on their own choosing but they cannot expect back porting of fixes by community It is expected that they will monitor critical fixes in supported branches including security fixes. They are also expected to maintain the forward fixes into supported releases and maintain upgrade path.

Release Management 

  • JIRA
    • Lots of open unassigned issues
    • Auto assignment and rotation of responsibility ever major release 
      • Auto assignment is obligation for assignee and as such will not be endorsed by community and given the impression of control
      • However we can define fine grained component / sub-component and volunteer maintainer list. People can add or remove their name as maintainer for specific components anytime.
      • We can set up filter for open issues and new issues which the maintainers can subscribe to.
    • Prune out older issues, if no one has picked up in a year. 
    • Components Deprecation Policy
      • If a component is not actively maintained and the community is not able to support it. It will be called out to be deprecated from the next active release and the notification sent to dev and user list.
        • Deprecation
          • Disable from UI and API
          • Open Item: When can we remove the deprecated component from source tree?

...

...