Re: [Jsynthlib-devel] Call for version 0.21

[Joe E. <jo...@em...>]

On 9/8/2011 3:10 AM, William Zwicky wrote:
> Note that I don't have permissions to post a binary, so we'll need a
> volunteer for that.  And if you'd prefer to be the one to BUILD the binary,
> let me know.

I can probably post the binary, but I probably shouldn't build it. I 
don't use ant or make or any of the tools which use the build.xml and 
other files which everybody carefully maintains.

> If you're working on something now, please respond with an estimate of how
> long it'll take (powers of ten - 1, 10, 100 days).

Well, while you're talking about releases, I want to mention something 
else about the refactor (now that I'm diving back into the code and 
remembering what the hell I was thinking at the time). The *original* 
refactoring plan was to make "core" go away, entirely. Everything in 
core was going to get neatly organized into org.jsynthlib somehow. Two 
things postponed this:
- CVS (which is what sourceforge was using at the time) didn't support 
"moving" files across directories. When they got moved, CVS would treat 
them as one file being deleted and another, unrelated one being added. 
This would affect people's ability to see diffs between versions on 
either side of the date when the file was moved. SVN, I'm told, *does* 
support moving, so it's my hope that this will preserve the revision 
history when the files get moved.
- When I saw how many synthdrivers and other UI components were 
subclassing Actions.MenuFrame, I freaked and decided to un-tangle that 
mess... which is what I'm just finishing up now.

If I move files around while I'm working in branches/UIRefactor, then 
that's going to create chaos when we try to merge this into trunk. So, 
I'm not going to move any existing files until *after* the merge to 
trunk, but they *will* move after that and everything will look a lot 
cleaner.

- Joe