Please note
This version of Fabric is outdated. If you're looking for the latest stable release, please click here.
The Fabric development team consists of two programmers, Jeff Forcier and Christian Vest Hansen, with Jeff taking the lead role. However, dozens of other developers pitch in by submitting patches and ideas, via individual emails, Redmine, the mailing list and GitHub.
Please see the Source code checkouts section of the Installation page for details on how to obtain Fabric’s source code.
There are a number of ways to get involved with Fabric:
If a ticket-tracker ticket exists for a given issue, please keep all communication in that ticket’s comments – for example, when submitting patches via Github, it’s easier for us if you leave a note in the ticket instead of sending a Github pull request.
The core devs receive emails for just about any ticket-tracker activity, so additional notices via Github or other means only serve to slow things down.
Fabric tries hard to honor PEP-8, especially (but not limited to!) the following:
While Fabric’s development methodology isn’t set in stone yet, the following items detail how we currently organize the Git repository and expect to perform merges and so forth. This will be chiefly of interest to those who wish to follow a specific Git branch instead of released versions, or to any contributors.
Fabric tries to follow open-source standards and conventions in its release tagging, including typical version numbers such as 2.0, 1.2.5, or 1.2b1. Each release will be marked as a tag in the Git repositories, and are broken down as follows:
Major releases update the first number, e.g. going from 0.9 to 1.0, and indicate that the software has reached some very large milestone.
For example, the upcoming 1.0 will mean that we feel Fabric has reached its primary design goals of a solid core API and well-defined area for additional functionality to live. Version 2.0 might, for example, indicate a rewrite using a new underlying network technology (though this isn’t necessarily planned.)
Major releases will often be backwards-incompatible with the previous line of development, though this is not a requirement, just a usual happenstance. Users should expect to have to make at least some changes to their fabfiles when switching between major versions.
Minor releases, such as moving from 1.0 to 1.1, typically mean that a new, large feature has been added. They are also sometimes used to mark off the fact that a lot of bug fixes or small feature modifications have occurred since the previous minor release. (And, naturally, some of them will involve both at the same time.)
These releases are guaranteed to be backwards-compatible with all other releases containing the same major version number, so a fabfile that works with 1.0 should also work fine with 1.1 or even 1.9.
Note
This policy marks a departure from early versions of Fabric, wherein the minor release number was the backwards-compatibility boundary – e.g. Fabric 0.1 was incompatible with Fabric 0.0.x.
Fabric 0.1 to 0.9 also marked a rewrite of the software and a change of hands, and so did break backwards compatibility. This will not happen again.
The third and final part of version numbers, such as the ‘3’ in 1.0.3, generally indicate a release containing one or more bugfixes, although minor feature additions or modifications may sometimes occur.
This third number is sometimes omitted for the first major or minor release in a series, e.g. 1.2 or 2.0, and in these cases it can be considered an implicit zero (e.g. 2.0.0).
Note
The 0.9.x branch of development will see more significant feature additions than is planned for future lines. This is in order to backport some useful features from the 1.0 branch so that the feature gap between 0.9 and 1.0 is not as large as it was when 0.9.0 was released.
In 1.0.x and so forth, tertiary releases are more likely to contain just bugfixes or tweaks, and not new functionality, as the window between minor releases is expected to be shorter than that of 0.1 => 0.9.
Major and minor releases do not mark the end of the previous line or lines of development:
We hope that this policy will allow us to have a rapid minor release cycle (and thus keep new features coming out frequently) without causing users to feel too much pressure to upgrade right away. At the same time, the backwards compatibility guarantee means that users should still feel comfortable upgrading to the next minor release in order to stay within this sliding support window.