Re: 1.3.5

On 6/16/06, Lübbe Onken <l.onken@rac.de> wrote:
> > I seriously doubt that an RC would have saved us here.
>
> Maybe
>
> > Not many people
> > actually use/install an RC.
>
> Not proven.

Experience.

> Sorry, this is just a concatenation of assumptions, made up to justify that
> you don't want to create RCs. If you don't want create RCs, for intermediate
> releases, don't do it (see below).

Sure these are assumptions. The same as your assumption that an RC
would have prevented this bug from going into the final release.

> How about a poll on SF:
> Would you test RCs?
> ( ) never
> ( ) maybe
> ( ) of course

Also ask if they would actually *report* a bug if they would find one.
Some people just try out RC because of the new features, they're not
interested in reporting bugs (I do that too with some programs).

> > Downloading an RC or nightly does *not* mean it also gets tested.
>
> Hrmpf, How many people download software just for the sake of downloading
> it? Once it's installed, it's under test.

Installed != testing.
Because testing includes *reporting* what you've found.

> > I really don't like the idea of pushing out RC's for
> > intermediate releases. I'm the one who has to do it, and I'd rather
> > spend my time with other things...
>
> That's about the only argument you presented that I can (or have to) accept.
>
> I checked our release history since 1.0 (~ two years) and I see at least
> eleven obvious quick bugfix releases (withing ten days of a previous

Never trust a statistic you haven't forged yourself. :)
Don't just check the release dates, also check the changelog. Back in
those days were much more releases, and every release included new
features.

> release). During that period we made four major, 27 minor releases and had
> three RCs up for testing.
>
> That means that 11/31 = 35% of our official releases were so broken that we
> had to fix them quickly and I am convinced that we could get below 10%

"so broken" - thanks for that quote. :(

> If uploading, adjusting the web sites and announcing everything everywhere
> is the part of the work that you don't like, I'll gladly do it. I can't
> build TortoiseSVN, but I can take care of the administrative part.

Yes, *that* the part that takes the most time (kidding here). Check
out the Release_procedure.txt please.

"These steps are required to generate the release:

- Check the latest versions of openssl, zlib and of course
  download any newer versions available.
- increment the version number in version.build.in file
- finish the changelog.txt file, i.e. add the version title
- run the Nant build script

if all goes well (no errors while running the script) install the new
version and test one last time.

Now commit those changes and then create the tag in the repository

- run the Nant build script again, passing the 'release' param.

The last steps:
- upload the files to sourceforge.net
"
Those are the steps I have to do for every release. Including building
twice and installing it (which requires a reboot as you know,
especially if you're downgrading from a trunk build).

What's left (and you offer to do) is:
"
- edit the web files download.html, index.html, project_status.html to
  indicate the new release
- edit the file version.txt to match the exact version number of the release
- copy the changelog file to the /www folder
- commit the web pages

Announcements:
- Mail to dev@tortoisesvn.tigris.org, users@tortoisesvn.tigris.org and
announce@tortoisesvn.tigris.org
- Add a news item on tigris.org
- Edit the version information on sourcforge.net
- Remember to include a link to the download page in the announcements.
"

I really don't get why you want an RC for intermediate releases too.
Not even the Subversion project does that. So why should we? Mistakes
(like the one causing this bug, which was simply a forgotten revision
when merging a fix) can happen, and will happen.
Even the Subversion project sometimes has to make a 'fast' bugfix release.

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