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

[James Rich <james@xxxxxxxxxxx>]

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