Suppose you’re the author of a software project. You spend your time developing new versions and prefer to add new features in new versions.
Suppose you’re the user of a software project. You prefer not to upgrade to new versions. You might want some new features.
Suppose you’re the distributor of a software project. How do you reconcile these desires?
I have some thoughts on backporting to publish in the near future, but I would like to get other perspectives first.
It depends who's paying. If it's my own project, then money (or whatever other lever applies) will often influence me to do the work that other people (users, distributors etc) want done. If you have no lever, then you get to use whatever I want to work on.
I think it depends on what kind of software it is, and the facilities available for making backports easy.
For example, if you have a plugin system, it's possible to offshore some newer features into a plugin, but with a compatibility layer so they work with earlier versions of the software.
This allows you to not officially support the features, but possibly put out a few fires for some folks.
But yeah, it depends if it's open source or not, and whether money is involved. I think ultimately YMMV.
Backporting is complex and confusing. Which version does one use? The developer's version of the software? The package maintainer's version? Or the version for your version of your OS? Even if you do not use all the new features, don't you want all the bug fixes and security upgrades?
I say backporting is evil.
Backporting is complex and confusing. Which version does one use? The developer's version of the software? The package maintainer's version? Or the version for your version of your OS? Even if you do not use all the new features, don't you want all the bug fixes and security upgrades?
I say backporting is evil.
Yeah, backporting (wether, or not) is one of those interesting problems... :)
I'd look at it from an API evolution standpoint, thinking of APIs in the widest possible sense (i.e. not only programming interfaces but also user- and deployment-interfaces and the effect these have on the organisation.)
Assume a software lifecycle graph, with time (and new releases, bugfixes and other "events" in the lifetime of a project) as X - and features (and APIs to access these and the added complexity this represents) as Y. Now if the software evolves without adding complexity/new features or make any significant API changes, you could assume it's cheap to upgrade. Add a feature, and the cost goes up. Obvious stuff.
Next question I'd ask is how do the deployment methods themselves affect this graph?
I'd guess they lower the upgrade barrier quite a lot - especially if one can make use of "fire-and-forget" package installation systems like the Redhat Package Manager or the Debian packages.
If we'd have a usable bridge between the CPAN distribution world and the major packaging systems - including cross-package dependency support - I'd guess quite a lot of sysadmins would be happy to install more often - including myself. :)
That's not the whole picture, of course. If a library developer decides to radically change the library's API, it won't matter if it's easy to install it. Things will break anyway, users will become sad, kittens will cry.
Would it be feasible to create a "package API history graph" for CPAN packages? E.g. something that registers how the public API looks like, so that one later can make an API diff between releases? Maybe that would help a little in convincing users to upgrade...
Another thing one could do to make upgrades "cheaper" is to define a standard machine-and-human-readable "Changes" file format, and make it's . :)
('nuff rambling for now. :)
I guess there is no reason to backport with today's techniques. Not good for propietary software. Not food for Open Source software... in some very especial cases it would be a necessary evil, but for most of projects you can just disregard the concept.
I think Open Source projects do better on both desires.
Sticky one, but I would say there might be situations where a backport was good. In the Tcl community, 8.5 is almost out and they added a "dict" to the language. People really liked it, so it got backported as a package for the 8.4 folks to use as well. I think something like that works well. I think you have to think very carefully through something like that.
I don't like back ports as used by Linux distributions.
If an original source package has a fix that generates a new version number, it is hard to determine if this fix has been included in the package from the Linux distribution because the version numbers are out of sync.
Backports are really a special case of backward compatability. I think this is necessary for applications that integrate components from different developers (i.e. almost all of them).
If you hit a critical problem with an application or one of its components, and don't have access to backported fixes, the application will be useless to you until all of the components that go into it have moved on to compatible versions without the bug.