2022 08 15 Open NEST Developer Video Conference

previous | list | next

Agenda

1. Welcome
2. Review of NEST User Mailing List
3. Project team round
4. In-depth discussion
   • Version numbers in NEST and dependencies

Mailing list

• https://nest-simulator.org/mailinglist

Project team round

Here we discuss topics that need broader attention, for example questions that came up but are outside a single project's scope, larger planned changes/PRs that affect all teams or pending work that is blocked by external factors.

1. Models / NESTML
   • updated NESTML CI, nest-version dependencies
   • integration of NESTML with NEST-Desktop has started
2. NEST GPU
   • started merging both python interfaces, aiming for the same pynest interface
3. PyNEST
   • no report
4. NEST Desktop
   • no report
5. Kernel
   • no report
6. Installation & Infrastructure
   • release process towards nest-3.4
   • cleaned release dependencies with doc team
   • discussion of API version (see below)
7. Documentation
   • business as usual, working on PRs
8. EBRAINS
   • no report

In-depth discussion

• NEST Version / API

• Dependent tools require fixed release numbers or known API versions

• builds from git repo do not have a semver number, but instead "master@", which causes problems in some cases

• C++-API and pyNEST-API are not separately versioned at the moment

• installers should know version dependencies (e.g. pip install nestml)

• solution needs to be very maintainable, i.e.

  • API definitions might need a lot of management
  • intricate setup mechanics requires constant maintenance

• APIs are "promises" to the outside, community sometimes uses direct accesses, breaking API boundries

• since NEST-2 incompatible changes in "the pyNEST" API has been signaled in the major version number, NEST-3.x

• new features added would more consistently require a version bump (NEST or NEST-API)

• direction of dependencies needs to be clarified to list "supported versions" (e.g. NESTML <-> NEST)

• two points:

  • better technical solution (version number formatting and technical realization)
  • better version semantics

• dependencies must always be on releases only (never on features in master)

• need to avoid situation where tools need to be released in lock-step. All tools must always be able to release (based on released dependencies)

Developer territory

• when developing new features based on un-released versions of dependencies, the version numbers are not easy to determine from repository states.
• suggestion: add last release number to the repository to be reported, e.g. "3.3_post_dev" in master after 3.3 release.
  • should be parsable by semver
  • NEST-release defines the APIs