The release machanism per se is OK currently, I think, in that a package creator has to explicitly name a release and upload the release file (which, as I mentioned above, I'd rather see stored in the download repository so all downloads reside in one place, with links from the SDM for managed code, of course).
But Lars makes a good point that there's poor integration between releases and bugs.
This is always a troublesome thing - we should default to the latest version, of course, but folks don't always use the latest version and can't always test against the latest version. Which adds to maintenance overhead, unfortunately, and makes errors in data entry probably unavoidable.
When bugs are fixed they should be marked as fixed in the "next" release no matter which release they've been reported against, though. I say that because I don't forsee us trying to maintain past releases but will manage the project by moving forward and fixing bugs in for the next release. People can download patches to patch their existing systems of course (a good reason to require patches be filed for bug fixes, actually, if you think about it!).
So essentially all bugs fixed after release "(i.j.k)" can be marked as fixed in release "(i,j,k)++" in our linear release scheme, at least.
We can make this the default anyway ...
As far as workflow goes ... I've done some work integrating workflow into a "normal" package UI and have workflow panels that work both from within a package and from within the workflow UI (template "include" is your friend).
So it is possible to use workflow and to have a decent UI - if you don't depend on the built-in workflow UI for tasks, that is.
As Luke mentions, the workflow UI ain't really quite there yet in terms of user-friendliness, but if you let your users work through steps naturally within the package framework that's not really an issue.
I do want an improved workflow UI - I like the idea of a user being able to approach all their tasks from a nice, well-designed central workspace. I also like being able to dip into a package and do my work that way, and workflow allows that to be done seamlessly if you work a little workflow panel magic.
Workflow's not integrated with permissions while the rest of the toolkit generally uses permissions to decide "who can do what", in my mind that's another practical problem that needs solving.
I've got some other notions about workflow, too, that have grown from my use of it.
So ... I wouldn't recommend against workflow though I agree with Luke's assessment of the parts of the package UI.
