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 -
