[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: TortoiseSVN 1.3.1 released

From: Stefan Küng <tortoisesvn_at_gmail.com>
Date: 2006-01-26 12:49:43 CET

On 1/26/06, Matthias Wächter <matthias.waechter@tttech.com> wrote:

> I think that in the change log for each listed entry there should be a
> bug tracking issue number applied. This is not only for someone like
> Célio who is interested in his own bug observations but also for developers.

Do you know that this would increase my workload at least by a factor
of two? Most of these bugs are very small and fixed in no time.
Creating an entry in the issuetracker would take sometimes more time
than to fix a bug.

> I "like" programs with change logs like the following:
>
> [...]
> v0.9.1:
> - various minor bugs fixed

That's a valid entry for a changelog. Changelogs have to be short, so
listing every little change isn't possible.

> v0.9.2-0.9.4:
> - internal testing revisions, never published, some changes

Ok, that's lame.

> v0.9.5:
> - various minor and major bugs fixed, prepare for release

The major bugs should be at least listed separately.

> v1.0.0:
> - various minor bugs fixed, thanks for the reporters!
> - new features, test them out!

Here too, the new features should be listed.

> v1.0.1:
> - major security bug fixed - please update now!

Security bugs require a detailed description. But not too detailed,
otherwise some bad guys have it easier to exploit them.

> If I can't find more information on a specific version change (neither
> by bug tracking issue number nor by asking on the mailing list (!)) the
> whole change log is useless and I immediately lose confidence in the
> quality of the product. But maybe this is no issue for the developers
> since "It's Open Source Anyway"(TM).

When I specify "fix crashes on SMP systems", I think that's enough.
After all, if you haven't had a crash, you know it won't affect you.
If you had however some crashes, then you know you should update.
What good would it do if I explain in every detail where/when/how such
a crash can occur? Especially bugs which occur only on SMP systems,
those can't be triggered reliably but happen only occasionaly due to
multithreading and processor cache hits.
Most people won't even know what that is, and definitely don't care.
Those who do, can always check the commit logs, do a diff, ...

Also, some bugs, while fixed in a minute (e.g. wrong variable used,
wrong if() check, ...) can require a one page long explanation on when
this really affects you. It's not uncommon that such a bug can only be
triggered if multiple settings/setups must be set specifically or you
won't even notice them. So listing all those just for a one-line fix?
You must be kidding!

Stefan

--
       ___
  oo  // \\      "De Chelonian Mobile"
 (_,\/ \_/ \     TortoiseSVN
   \ \_/_\_/>    The coolest Interface to (Sub)Version Control
   /_/   \_\     http://tortoisesvn.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Thu Jan 26 12:50:02 2006

This is an archived mail posted to the TortoiseSVN Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.