[asterisk-scf-dev] Component Repository Organization

[Joshua Colp]

Hello all,

I originally crafted this component repository organization document on the wiki since it was the easiest place to do so but to bring maximum exposure and discussion I'm posting it here. Once the discussion comes to a conclusion I'll then update the wiki to reflect changes.

Overview

Organization of source code is an important matter for software projects. This document aims to describe the approach taken using multiple repositories for Asterisk SCF components and why this was initially done. Hopefully this will serve as a starting point for a discussion of whether this is the right way to go forward for the Asterisk SCF project.

Multiple Repositories

Asterisk SCF, being made up of different components, currently has each component in its own git repository. This was done because it was thought that the components would not all follow the same life cycle, release management, and versioning. With this in mind, the separation of the git repositories makes sense. Independent repositories are also consistent with the loosely coupled nature of Asterisk SCF.

Lifecycle

In many systems, components under development often undergo independent lifecycles: some components reach maturity quickly and remain relatively static while others are constantly evolving. Even after a system has become "mature" and stable, some components may require more maintenance then others and may even be replaced by entirely new components. We anticipate that this will be the case with Asterisk SCF components as they are independent of each other and not modules of a single process. This will also have an impact on component versioning and release management.

Release Management

It is perfectly reasonable for some components to be released much more often then other components, simply due to their complexity and usage. For example, a component that simply provides a ulaw transcoding resource may only be released a few times a year due to minor changes while a component providing SIP session services may have update releases every month. Releasing components separately has important consequences for deployers: specific components can be upgraded without affecting the entire system. Keeping the components in separate repositories makes it much easier to accomodate releasing components independently.

This does not preclude a single release of an Asterisk SCF system. Since each component is tagged as it is released, a script that constructs a distribution from the current Asterisk SCF components is straightforward. Such a distribution is analogous to a Linux distribution where an initial release contains the packages that are current at the time and may be updated as fixes and improvements are made.

Versioning

With releases comes versioning. Asterisk SCF has three versioned items: Entirety, Component, and Interface. Due to the low level versioning of the interface it is entirely possible for components to be deployed at any given time with different interface version requirements. There is no strict requirement between components to be completely up to date unless a specific feature requires it and that feature is to be used. This further reenforces the idea that components can be released and developed independently without harm. For component versioning a component can be individually tagged in git. This is not possible in a combined repository because tagging applies to the entire repository. This would require careful staging to ensure all components are in a state where they are in complete working order and ready to be tagged. This would also make it incredibly difficult to have individually versioned items.

Additional Benefits

Some additional benefits of separate repositories include the ability for users to pick and choose the components they want to use to build their Asterisk SCF based platform. They do not have to grab everything just to build a few things.

Repository Groups

Instead of having repositories exist in one directory they are stored in repository groups. Each repository group has a specific role.
team

This group is used by individuals to store their own repositories for whatever they may want to do. Contributors are expected to push their repositories containing changes to this group for review. Once reviewed the changes are migrated to the component in the integration group.
integration

This group is where active development on components occurs. Once a component reaches a point where it has been reviewed and released it is moved to the release group.
release

This group is where released components exist. This is the last step in life cycle of component repositories.

Thanks for taking the time to read the above and provide any comments/feedback/suggestions.

-- 
Joshua Colp
Digium, Inc. | Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at:  www.digium.com  & www.asterisk.org