Re: More on possible problem with Neon 0.25.0 [was Re: 1.3.0 RC1 ready to be rolled]

Greg Hudson wrote:
> Using the 0.25.0 situation as justification is bogus. It's to be
> expected that there may be regressions in x.y.0 releases of software;
> regressions are not generally expected in x.y.z releases.

If you are going to make that argument, we should use a regex that
excludes x.y.0 releases out of hand. ;-)

Just for arguments sake, lets say that x.y.0 - x.y.4 are smooth
transitions and Subversion has a release after x.y.4. Then x.y.5 comes
out which contains a serious buffer overrun exploit that takes months to
identify (thus meaning it is in wide usage).

If our logic is that we support x.y.0 or better, then we must roll a
release of our own to knock out x.y.5 from our supported range, on the
off chance that someone will use the x.y.5 release.

On the other hand, if we had explicitly listed x.y.0 through x.y.4 as
being tested OK, the _only_ people who would be at risk are the ones who
explicitly overrode our version limits. When Subversion next releases,
we simply skip the bad x.y.5 release and peg the max to x.y.6. It's all
about limiting the possible damage.

> I don't understand this argument at all, but Eclipse was a random
> example pulled out of a hat.

My point was that Eclipse is loosely coupled with Subversion and
Subversion is tightly coupled with Neon. The appropriate rules are
different.

> If we found out that external projects
> were discouraging people from upgrading to Subversion bugfix releases
> simply because they hadn't gotten around to testing our bugfix release
> themselves, we would be rightly peeved at those projects.

This happens all the time. It's called RedHat (or Mandrake,SUSE etc.).
  The distros update when and if they feel like it and we have to deal
with the user list traffic. And it suxs. ;-)

John

-- 
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD  20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org