What Precisely is a Rolling Distro or Release?
 

I can't find a definition that has edges where the different meanings don't cross the lines to another definition.

Where does the Release numbers fit in?

Where does Presto fit in?

No one is starting their code from scratch so why is it that all types of code are not a Rolling Release? If code is update-able it is in some form "Rolling" is it not?

Thanks in advance!

Let's take two distros as examples:


1. Slackware (uses the traditional release model): When a new version is released you receive it with a set of software components of a particular version, e.g. Slackware version 13.37 comes with glibc 2.13, bash 4.1, Gtk 2.24.4, KDE 4.5.5, etc. These components will only ever be updated if critical issues are found (e.g. security problems) and will typically only be updated to the next stable version that resolves that issue. This means for example that Slackware 13.37 will never get KDE 4.8.2 in the official distro. Slackware users who want a more recent version of KDE either have to upgrade KDE out of sync from the distro or they have to wait for some future Slackware release that includes a newer version of KDE.

2. ArchLinux (uses a rolling release model): Has no version number (although its install disc image does). If a user installed it it around the time when the Slackware team released 13.37 it might have had similar versions of software components. However being a rolling release distro, Arch upgrades the software components as soon as the Arch developers consider the new version stable, even if the new version is a major upgrade. So by now an Arch users would be running more recent versions of the various software components, e.g. glibc 2.15, bash 4.2, Gtk 3.2.3, KDE 4.8.2, etc.


In summary, a rolling release distro will update constantly to the latest stable version of a given software component (even where it involves a major update). Non rolling-release distros only receive critical updates throughout their lifecycle. To get major updates on a distro using the traditional release model the user must typically update the whole distro to a new distro version, or compile their own versions of the components they wish to update.

If you want to make sure you are always running the very latest and greatest of every piece of software then a rolling release distro might be a good option. The downsides being increased chance of breakage (due to less testing) and the functionality of software changing from time to time. A non-rolling release distro is a better choice for stability and predictability.

Note: The situation can sometimes appear confusing when you look at certain software components, like browsers. Both distros offer Firefox 11.0, which is the latest available major version. This is despite the fact that Slackware 13.37 shipped with version Firefox 4.0. So it might initially seem that Slackware broke the rule of only having critical updates since it has updated through 7 major versions of Firefox. However, this is actually not the case. The Mozilla team only made many of the fixes for various security issues available through major version updates, so the Slackware team had no choice but to offer major updates to Firefox to keep their users secure.

Wikipedia explains it quite well:
Rolling release - Wikipedia, - https://en.wikipedia.org/wiki/Rolling_release

Thanks for the Replies!
 

Versions must be a method to distinguish the time line sort of speak of your application I would guess.The time line would be directly related to the reasons changes had to be made to the code. Version numbers must be a way to I.D a the functionality of your Application.



What makes an Application update-able or what makes a developer choose to use a different version number? If you don't use a Version Number how do you I.D what is essentially a different Version? It would still work with different dependencies?


The definition of a "Rolling" Release looks like your own computer is running the developers code from their Text editor with an interpreter on your hardware which of coarse is not the case.

What is a Major Upgrade?

Where do dependencies fit in?

It looks like what is being said is that dependencies will not be updated unless necessary for the application in a NON Rolling Release where as in a Rolling Release the Libraries will be changed to the Next Version no mater what. Fedora ,Mandriva and Mageia will update libraries so ...???

I don't understand why anyone would offer or anyone would install a Application that was still in the process of being written.

:hattip:

Starts to wonder; if all the questions that a simple Google search could answer, are part of a homework assignment.

Go search and READ, the Wikipedia article either answered your questions or had links to more info that will.

That describes virtually all software that hasn't been abandoned or reached EOL. Software is constantly being refined. Most people choose to sue the latest stable version until the new updates and added features prove stable. Some like to have the newest features NOW even though they don't always work right.

Perhaps the best example of people using an application that is in the process of being written is the new (as of version 4) Firefox which is in a constant state of rewrite and moves (not necessarily for the better) at a developemtn speed that is both reckless and, imho, counterproductive.

Consider two basic "upgrade" methods in a binary distribution:

1) Incremental
a) The changed binaries are replaced. Unchanged binaries are untouched.
b) Settings, config and local customizations that haven't changed format are untouched.
c) Settings, config and local customizations that have changed format cause automatic translation routines to run to fix them.

2) Reinstall
a) All binaries are replaced whether they changed or not.
b,c) All settings, config and customization is left behind. The user is responsible for any copying, reestablishing, translating etc. of such things.

If you pretend that either of the above really exist as purely as I described, then a rolling release is one in which every upgrade is available in form (1). A non rolling upgrade is one in which (typically) some upgrades are available in form (1) but others only in form (2).

The question becomes blurred because (1c) can't be perfect. So how big an exception in (1c) does it take for an upgrade to not really be form (1).

The question is also blurred by time scale. How long does a distribution need to offer every upgrade in form (1) to be "rolling".

A source rather than binary distribution adds some more blur to the meaning of "rolling".

All software is potentially updatable. And software developers typically increment the version number whenever they put out a new version that includes any changes over the previous version. Distros may or may not use version numbering for the distro itself. Arch does not use version numbering for the distro.

I think you have the wrong idea here. Most rolling release distros typically provide you with a collection of software that is the the latest public stable version of the various software packages that make up the distro. No distro (rolling or not) that claims to have any decent level of stability is giving you development versions of all of the included software. There might be a few cases where some software is considered good enough by the distro maintainer but not officially marked as stable by the developer of that software but these cases are generally in the minority.

An upgrade where new functionality is included or other big changes made (e.g. a change in the user interface). As apposed to a minor update which will typically only have bug fixes and nothing else.

It looks like you have gone off on a strange tangent here. Dependencies are kind of irrelevant at least as far as rolling or non-rolling release distro methodologies go, i.e. they are treated in exactly the same way on both types of distros. Just because you change a program that does not necessarily mean that its dependencies will change. However if they do (i.e. the new version of software X needs a newer version of library Y and now also requires library Z) then the dependencies must be updated as well, regardless. If a dependency must be updated it will be, if not it won't.

This does not really relate to rolling release or non-rolling release distros at all. That said, many people install development versions of software. The advantage to the software developer is earlier testing and feedback on issues relating to the work in progress software. The advantage to the user is they get to try out new features early, at the expense of some things being broken and the application not working perfectly.

ELF file angle
 

Will a Rolling Release update a single binary in an ELF file while a Update with different Versions throw out the whole ELF file?

I think you have a misunderstanding of updating. Both, rolling release and fixed release (I think version is the wrong word here), update in the same way: delete all files that were installed from the old package (except configuration files of course) and the copy all files from the new package to the filesystem. The question if a distro is rolling released is not "How do they the updates?", the question is "When do they the updates?".
Take for example a rolling release like Arch in comparison to a fixed release cycle like Debian:

Arch: Whenever the developers think that a specific package is stable enough (after a short time of testing) they release into their repositories. When you update your Arch system you get that one package. If the package has new dependencies to be fulfilled then you will get those dependencies, too. A package won't (normally) be released when the dependencies are not considered to be stable enough.
This makes the system somewhat stable, but due to the short testing time breakages may happen.

Debian: They release a version of their distro, let's say Squeeze. From now on, Squeeze will only get one type of updates: Security fixes. No new software will be introduced, no version updates happen. The next version of Debian will be developed with newer software totally independent from Squeeze in a different branch, called Testing (or Wheezy, how the next version will be called). New and somewhat tested software (tested for a few days in Debian Unstable, but that is a different story) comes to Wheezy and will be further tested and eventually replaced with newer versions. One could say that most (if not all) development versions of fixed release cycle distros are themselves some kind of rolling release. At some time the Debian developers decide to make a freeze. from that point on no new software is allowed in Wheezy, only bugfixes and security updates are allowed. When the developers decide that the bug-count is low enough the release the new version. When you update your system from Squeeze to Wheezy all packages that are available in newer versions in Wheezy will be replaced on your machine. That is a large part of the system, but not necessarily all packages have newer versions (like the ed editor, for example).

So, in short: rolling release = constantly updated with newer packages that the developers think are stable, fixed release cycle = only security updates (some distros allow bugfixes) come constantly, the rest is a one-time job.

Thanks for the Great Replies!
 

I thought that Presto only replaces the code in a dependency that is different,(some times I miss Fedora).


I can't understand how a Bugfix does not create a different Version of some sort. Edit:There has to be a log that keeps track of if the Application was altered with the particulars of this Bugfix.


I assume a Bugfix remedies a problem of how the Application was intended to work while a New Version adds a new function that the Application did not have prior.

How does a new Package make life so miserable for a Distro? I thought that is what the O.S and system calls are for.:scratch:

There are two answers for this question. At first, a new package may change features in the packaged software. This is a no-go for a stable distribution, they want to have a feature freeze, so that the user can always expect the exact same behavior. This is a must for distributions in enterprise environments.
The second: A package doesn't have to be an end-user application, it also can be a library on which many applications depend (may be a part of the OS). A change in such a library can break those applications. Therefore even in rolling release distros there is a short testing period, but this period is not long enough that one can guarantee a stable system. this would need a much longer testing phase. This is simply not doable for a stable distro. It is easier to not change the package in the stable branch and put the new software into the testing branch.

There is a third approach to that: Chakra for example tries to have a stable base system and only the end user applications are released in a rolling release manner.

Thanks for the Patience and Attention.
 

Now I should be able to follow the Wikipedia article.:)