From Open Sustainability
|
| This article is refer to an aspirational goal of the FISDEV methodology. It refers to the generally applied approach from the Open Methodology Framework that will be more relevant once FISDEV has reached a mature state.
|
The concept of a Release Cycle is an important part of the Open Methodology. One of the key differentiators on the collaborative FISDev approach is its ability to change to adapt to new techniques, technologies and methods. Supporting Assets are added continuously to the methodology from various contributors, but FISDEV also needs to provide a degree of stability to its users. This is done through Releases Cycles and the Contribution Model.
Release Cycles are a grouping of FISDev Content into a selected baseline at a point in time. Content that is part of a Release Cycle can only change at a pre-defined time so that users know the content they are working with is stable. Just as with software components as part of an overall package release, not all articles will change with a particular release and users will be able to access previously released versions of an article.
Relationship to FISDev Content
Different types of FISDev Content operate within different Release Cycles:
Core Methodology
The Core FISDEV Methodology includes the Overall Implementation Guide, Usage Model and selected Supporting Assets and Solutions. This aspect of the methodology is more stable and only changes at different Release Cycles. Mapping of Supporting Assets into the overall approach also occurs as part of a Release Cycle.
Non-Core Solutions and Supporting Assets
Solutions and Supporting Assets can be added to the methodology in a continuous fashion and provide the promotion path through adding more detail or extending the overall approach. All Supporting Assets go through their own independent cycle of development, often starting as a Wanted Article or Stub before going through the Peer Review process to become a more mature article.
Unlike the Core Methodology, where changes to content happen as whole (i.e. all changes happen at once), each Supporting Asset has its own release cycle unless it becomes a Core Supporting Asset, at which point it is only undergoes changes as part of a Release Cycle. FISDEV Solutions can also become part of the Core FISDEV Methodology.
Therefore, users of Supporting Assets and FISDEV Solutions that are not part of the Core FISDev Methodology need to use caution in that they may not fit in well with the overall FISDev approach. The lower the level of maturity of an article within the Contribution Process, the less the article has been reviewed in terms of its relationship to the overall methodology.
Release Cycle Delivery Roadmap
As best as possible, the Methodology will try and provide a Product Roadmap of planned changes and enhancements. These will be largely at the major functional level and will go out on a projected horizon of 6 - 12 months. The methodology will track its progress against these planned delivery milestones and use them to help drive work efforts and focus.
The Product Roadmap will be driven from requirements which come through Wanted Article and Stub and the guidance of the Open-sustainabiliy Governance Association.
Revisions to New Functionality Releases
FISDev will be be focused on progressively building functionality across the overall approach and its more detailed assets. There will, however, be times when the Core FISDEV Methodology will need to revised - such as when:
- A particular approach is shown to consistently yield poor results
- Technology advances render an old approach as out-of-date
- A piece of new functionality changes existing dependencies
These changes can be seen as "defect releases" and will generally be focused on a particular article or group of articles.
Backward Compatibility
As FISDev will be in use by implementation teams at all different point on projects, new releases should offer a transition from the old release to the new release and help accommodate users who are currently in the process of using the methodology. Much like a software release, "defect" releases should result in a change to the existing approach whereas new functionality only needs be used when required.
Contribution Model
The Contribution Model provides the hierarchy of what users can change certain articles; for example Protected Content can only be changed by members of the Leadership Team for FISDEV. As with the Release Cycle, the purpose of the Contribution Model is to add stability to the FISDEV Methodology that balances the continuous enhancements being made to the overall approach.
