Re: [Csnd-dev] Csound 7.0 release planning

I've got a couple of items I'm looking at:

* Finishing pass-by-ref for new-style UDOs (was dealing with merging
latest from develop and working out through the changes from local sr
that affected UDOs)
* Fixing expressions (there's issues I've seen come up in some of my
live coding, need to diagnose further and resolve)

I haven't announced it but I've put together CsoundFFM
(https://central.sonatype.com/artifact/com.kunstmusik/csoundffm) for
using the Csound API from Java (requires Java 22). It works with
Csound 6 and the current develop branch but will need to be adjusted
for newapi changes. It does not fully wrap the Csound API yet but
should be easy to extend and maintain. I think this is the way to go
but requiring Java 22+ might not work for everyone. Needs a community
survey to see, but I'd prefer CsoundFFM be the main binding moving
forward. (It'll be what I use in Blue at least.)

Note: We still use SWIG and JNI for Android. I don't think there's any
option but JNI for Android for interfacing with native libraries? We
could remove producing the java library for linux/windows/macOS, but
we'll need to maintain what's there for Android.


Besides the PRs already to go through, there's two things I'd like to
see before the conference:

* code formatting/linting
* code folder reorganization

I think it's best to get through other things first but I do think
they're worth getting done for 7.0.




On Wed, Aug 14, 2024 at 7:08 AM Victor Lazzarini
<[email protected]> wrote:
>
> Hi everyone,
>
> we’re about 1 month away from the Csound conference. I think it’s  time for us to begin discussing a plan to complete the release of version 7.0. Given the short time we have, we will need to prioritise what  we can deliver. Here’s a few points from my perspective:
>
> 1) we need to assess what we have to do now that cannot be done after the version bump. In my mind, this is mainly to do with keeping API & ABI compatibility.
>
> 2) API: we have to decide what is our starting point. It is possible to add functionality in latter versions (hosts using this may require a minimum version > 7.x) as we have done many times before.
>
> 3) Internal changes that do not break ABI compatibility are OK so we can leave things still to be implemented.
>
> 4) Restoring parts of the engine that are currently broken: there is one known instance in the parser that breaks backwards compatibility (multiple variable assignment, test3.csd) and CS_PAR semantic analysis has been removed from the parser. I think these two things need to be fixed before the release.
> For CS_PAR we can optionally disable the option until this can be looked at.
>
> 5) Testing: we need to test the software more thoroughly, particularly the new additions (parser etc). Perhaps that is where the focus should be now?
>
> As far as the new API status is concerned, I think we have the basic wrappers in the repo in sync, iOS, Android, WASM, ctcsound (may need a check); the Java wrapper is still an open question, should we keep maintaining one?
>
> Finally, once we have made these decisions, we will need to see how releases will be built. I can continue to make MacOs and iOS packages locally but it would be more solid if these could be built by an automated CI service. At the moment, we build for these platforms in actions, but these builds are not designed for release (they have external dependencies from brew etc). We would need help to implement this properly. Similarly, we would need to do the same for Android.
>
> Victor
>
>
>
>
>
>