HUSKY
Portable Fidosoft Project
- Main
- Main
- History
- What is Fido?
- Husky Team
- CVS Server
- FAQ
- History
- Husky Versions
- Overview
- Current Husky
- Stable Husky
- Download
- Debian Packages
- Current Husky
- What do I need?
- Point
- Node
- Basic Files
- huskybse
- smapi
- fidoconf
- smapi
- Tosser
- hpt
- Editor
- msged
- Netmail utilities
- cfroute
- lxtrack
- ffma
- bsopack
- lxtrack
- Nodelist tools
- promknl
- nltools
- fastlst
- nltools
- Tickers
- htick
- protick
- Gateway
- progate
- Mailers
- emailpkt
- diskpoll
- Tools
- sqpack
- mpost
- gff
- fidostat
- huskypnt
- huskmisc
- mpost
Stable Husky
Stable Releases
When we want to release software, we take a snapshot of current Husky as root for the stable development branch. In this branch, only bugfixes will be made, but no new features will be implemented. In particular, we will not make disruptive changes that require you to make adaptions to your configuration file, or to re-build all libraries and programs (i.E. we do not change calling conventions for the dynamic libraries).
When the software is ripe for release, it will have the version number of the current Husky snapshot it stems from, followed by the word release. Example: msged 6.0.0-release
Starting in Fall 2001, the minor (second) version number of all stable branches will be divisible by 2; I.E. 0,2,4 and so on. The stable branch as such is characterised by this second version number.
Before the software is released, it has the same version number as the release, but the suffix is -stable instead of -release.
Maintenance Releases
The stable branch will continue to live after the release. Bugs that are found in the release will be fixed in the stable branch. After a while, it may occur that we make a follow-up maintenance release from the stable branch. For this release, we increase the patch (third) version number of the software. Example: msged 6.0.1-release.
Generally, upgrading between software that differs only in the patch version number; I.E., software from the same stable branch (same second version number) is straightforward: Just plug the new executable in and go ahead. There will be no linkage problems and no behaviour changes, only bug fixes.
You may even upgrade to a new version of a dynamic library without having to recompile the software that uses this library (supposing you are using dynamic libraries / shared objects of course). E.g., you may upgrade from smapi 2.0.0-release to smapi 2.0.1-release. That is why the branch is called stable.
To clarify it, when a new stable branch is created, e.g. smapi 2.2-stable, you again have to be prepared for behaviour changes etc. when you upgrade from an older stable branch - only upgrading within a single stable branch is troublefree. Again: When only the letter behind the version number changes, you do not have to worry. In all other situations, you do have to worry.
In Software released prior to fall 2001, the versioning scheme was different. There, the patch version number was designated by a letter, and the branch was designated by the second and third version number together. I.e., in old software, you could only safely upgrade when only the letter changed, while in new software, you can safely upgrade whenever the seond version number is the same.
Package dependencies
As already noted, you must combine the Husky programs with the correct versions of Husky library packages to work. For a stable Husky release, the VERSION file found inside the archive, as well as the Husky hompeage, clearly states which packages are required. For example, msged 6.0.0-release requires smapi 2.0-stable. This actually means that any stable version of msged 6.0 runs with any stable version of smapi 2.0. When new maintenance releases with the same second version number (but a different third patch verison number) are made, you can choose to only ugprade msged, only upgrade smapi, or both. Of course, the higher the patch version number, the fewer bugs that will be there, but you do not have to upgrade everything just to get one specific bug fix.
Developers
In order to learn how to work with CVS when a stable branch exists, please read the file cvs-branching in the develop-docs subdirectory of the huskybse package.