Re: back-tab locks up 0.17.3 in Windows, with fix

On Wed, 19 Nov 2008, Scott Klement wrote:

That wasn't deliberate. At the time that we did the release, both of
them showed up on the same page near each other.

However, I think SourceForge changed their system so they only display
the latest release. At the time we set it up, they showed the last
several releases, but now they seem to only show the absolute newest one.

I figured something like that must have happened.

Last time you did a release, you didn't do the Windows part of it. You
just made the Unix/Linux/Source release. Then, I came by a few days
later and added the Windows one. Since the Windows one was the newest
one uploaded, SourceForge thinks it's the "latest" and doesn't show the
others.

That's just a guess -- and I hope I explained it well enough -- but if
we do a new release, I think we should coordinate better. Let's make
sure we have everything we need already committed, and release the Unix
and Windows stuff (plus any RPMs or other packages) together.

Totally agreed. Last time I think I made some mistakes that I definately don't want to repeat. Should we make a checklist of items that have to be done? I'm not aware of any code that must be checked in. The things I can think of to do are:

1. Make a source tarball that has the proper autoconf files already created.
2. Make install packages for common distributions (probably RPM - I can do Slackware because that's what I use - is there something specific for BSD?)
3. Make windows executable.

I can do number 1. I have no systems to test RPMs on, so someone else should do that. If no one else can create or test RPMs then in my opinion we shouldn't create one.

Thoughts?

James Rich

if you want to understand why that is, there are many good books on
the design of operating systems. please pass them along to redmond
when you're done reading them :)
- Paul Davis on ardour-dev