In the world of Linux there are typically two different types of release cycles: stable and rolling. While there are benefits to both, each have their weights in terms of making a system more or less secure. This article won't cover which one is right for you but will provide some tips and tricks to determine how you should view them and determine if you should use or the other. Stable Ever since I started using Ubuntu and Knoppix in my early days of Linux (early 2000's), this is the release cycle I was used to. It was similar to Windows' in that there was a designated date where major updates would come out and only important ones were pushed outside of that window. This releae method is pretty nice as it gives a lot of software developers and distro managers time to ensure everything is smooth sailing as well as a chance to iron out any bugs. From my experience the ones that use this system have a system in place where updates are no longer accepted for a specific release date so that the managers can spend time in making sure things work with each other. The way this system works is also its greatest downfall, however. If an issue is discovered after the cut off date, maintainers have to make a decision as to whether to allow the update or not, and then how to determine if other programs work as well. This can cut down production time if this is the case, so most maintainers seem to release hotfixes pretty quickly after the initial release date in the event this happens. Perhaps the greatest positive of this cycle though is that you are, with a very high certainty, guaranteed stable software when the updates are released as stable releases take on average at least a few months. You also have to wait longer, though, than rolling which can in the end make your system vulnerable. Rolling The rolling release cycle has really gained some steam within the Linux-verse over the past few years. I know some distros have used it for a while (Slackware and Gentoo I believe have and Arch is well-known for its use of this release style). In it, package updates are done in an immediate release style. Basically in terms of updating your system, stable releases happen rarely while rolling cycles happen relatively immediately. The pros and cons for a rolling cycle are polar opposites of the stable cycle, so there's not really any logical differences that I can outline. From my experience, the rolling cycle does offer a bit more of an advantage in that when (serious) bugs are found in software you get the fix a lot faster. However, there's also usually less (or no) testing done with the update so its also possible that something else can break when one issue is fixed. Which To Use There really is no definite answer here. In the work environments I've been through, I've seen it played out in one of the following ways: Rolling cycle is used but a custom repo is maintained Stable cycle is used but a custom repo is maintained Stable cycle is used but third-party repos are possibly used I've never really experienced an issue or found a reason to favor one over the other. I use a rollng cycle for my netbook but stable on my server, while my desktop has a rolling and stable system (depending on the distro I'm running). It would be nice to see a hybrid be pushed to a distro but there really isn't a reason to, at the same time. Most people who use a custom repo use it to manage specific packages while utilizing the default repos to manage system files (including Linux kernels).