Some weeks ago Fred Jan Kraan has reissued cyclone 0.2.1 as 'nilwind'
on github and deken. It happened upon my request, to enable
coinstallation of 0.2x with newer versions. Alexandre does a great job
in preserving backward compatibility (much appreciated!). But the
library has also been subject to major refactoring which happened
without publicly visible discussion or documentation of the approach.
Regressions resulting from this appear hard to solve.
Hi, thanks for the compliment, but I need to remind we're a team and Derek and Matt have done the hardest coding work ;)
I understand the concern and I wanna start by saying I can't see a problem with this branch/fork. Nonetheless, the main motivation seems to be "regressions that are hard to solve", and I don't know which cases you mean. The issue I see is if the description of this project makes such statements when no examples are given. If there are them, and I won't say it's impossible, it'd be good to know, so you can present what you're offering, and we could try and fix them, because we clearly don't have the intention to provide unstable releases with regression bugs - they should all be reported and fixed! For the moment, I don't know of any existing regression bug.
I think some unintended regression bugs are common in software development but we had just two of them I can remember, both have been fixed by the way. The first one was really silly (just an annoying error in [mousestate]) and fixed in cyclone 0.4. The last one was actually reported by you and I had just fixed it right before this email came up. It'll be part of the next release I'm planing to make as soon as pd 0.51 is out. As I discussed with IOhannes these days on this list, I said I'm also willing to support back the capital letters for backwards compatibility.
For this reason it is useful to have old cyclone still at hand as a
fallback. With nilwind around I could finally release an update of a
cyclone-dependent project without worrying about stability. Fred Jan
declared his intention to maintain nilwind for this sort of purpose.
Serious bugs and issues arising from external conditions may be fixed,
but behaviour of objects won't be changed otherwise. The lib name says
it all.
Again, no problem with this, but I'd really like to stress I don't see stability concerns in the current cyclone. As for "serious bugs", we did take care of countless of them which affected existing 65 objects, not to mention a newly written documentation that took care of many issues as well. I could argue this has actually improved stability and not the contrary. Yesterday I also just fixed an old bug with [active] that was not a regression of ours and we still have a list of known issues and bugs (none of which are regressions) to take care of posted in our repository. Roadmap and planing stuff is also available there. Our project has clearly lost steam, but it's still alive and I'm planing to try and put a new release out at least at every Pd Vanilla update.
Renaming a library doesn't automatically resolve name clash of
individual classes. It is therefore recommended to instantiate objects
with the library prefix, as [nilwind/<classname>]. This is also how
cyclone and nilwind help patches instantiate objects.
I think if you do [declare -path libraryname], it will force to load the object from that library as a priority.
cheers