Backporting policy

[Panu Matilainen]

On Thu, 8 Jan 2004, Warren Togami wrote:

> Charles R. Anderson wrote:
> > On Thu, Jan 08, 2004 at 01:28:04PM +0000, Christian Pearce wrote:
> > 
> >>Interesting.  I backported ethereal yesterday, even though RHL9 was
> >>an upgrade.  I can't believe they did that.  I generated a patch
> >>myself from CVS.  I believe everything works fine, I still need QA
> >>and testing to be done.
> > 
> > 
> > I think it is a myth that all Red Hat updates are backports.  Ethereal
> > has always been upgraded rather than backported:
> > 
> > ethereal-0.9.11-0.90.1.src.rpm
> > ethereal-0.9.13-1.90.1.src.rpm
> > ethereal-0.9.16-0.90.1.src.rpm
> > ethereal-0.10.0a-0.90.1.src.rpm
> > 
> > I actually preferred this for ethereal, since I like getting the new
> > features :)  Also, API changes are not really a concern with ethereal.
> 
> I think we should also consider upgrading in cases where all of the 
> following conditions are met:
> 1) Absolutely zero cases where API changes would effect any distribution 
> OR 3rd party software, because the updated package is a leaf node on the 
> dependency tree.  I suspect screen may be another leaf node.
> 2) Where having a common %{version} across multiple distributions would 
> make it easier to maintain security updates, because patches need not be 
> ported and tested multiple times.
> 3) Only by consensus of the list membership.
> 
> Thoughts?

I would add to that
4) New version doesn't have incompatible configuration file format changes

I suppose most end user applications can more-or-less migrate old settings 
to new format in such a case, which I think is ok, but if not then user 
settings should not break when upgrading a package. Of course it's even
more important for server software and such.

	- Panu -