subscribe to this blog

CubicWeb Blog

News about the framework and its uses.

show 144 results
  • CubicWeb Monthly news April 2021

    2021/05/12 by François Ferry

    During this period, we tried to fix issues, migrate some of our code base to latest version of CubicWeb. We also pursue some archeology tasks : merging or closing some merge requests from the old heads in CubicWeb's repository. We also release new version of logilab-database, RQL and CubicWeb!

    CubicWeb 3.31, RQL 0.37 and logilab-database 1.18 are out!

    We released Cubicweb 3.31, RQL 0.37 and logilab-database 1.18 on may 4th. The biggest change is the addition of two new RQL options: NULLSFIRST and NULLSLAST.

    The NULLSFIRST and NULLSLAST options can be used to determine whether nulls appear before or after non-null values in the sort ordering. By default, null values sort as if larger than any non-null value; that is, NULLSFIRST is the default for DESC order, and NULLSLAST otherwise.

    Furthermore, a lot of issues have been fixed, and a few new features have been implemented.

    Here is an extract of the changelog:

    • handle same_site cookies configuration in pyramid.ini
    • rql: add support for order by NULLS LAST and NULLS FIRST
    • improve default cubicweb skeleton
    • dbcreate: don't ask confirmation to create schema in automatic
    • hooks/notification: BREAKING CHANGE correctly initialize operation with event attribute
    • RQLExpression: performance issue on RQLExpressions using EXISTS() BREAKING CHANGE: explicitly use EXISTS in RQLExpression for permissions
    • fix some security issues

    One can find the full changelog on Cubicweb release page here.

    Adding python types to RQL

    In the past months, python types have progressively been included in RQL. This is a step forward to python types in CubicWeb itself.

    A lot of work has been done, and there is still a lot of work to do. Adding types to RQL help us to simplify the refactorings. As RQL's API is not clearly defined, we will run CubicWeb's tests on each merge request of RQL, to make sure nothing breaks.

    Future works

    More hackathon, more developpements!

    To have more time to develop CubicWeb, we will try to save a day each month to make a hackathon.

    Better handling of large databases

    In some CubicWeb projects, we have more and more data to manage; and databases are getting bigger and bigger. In the near future, we need to optimize the way CubicWeb deals with large databases. Table partition? More options to create indexes? We are also planning to have part of our databases checked by db experts to see what we can do.

    See you next month!


  • CubicWeb Monthly news february/march 2021

    2021/04/09 by Simon Chabot

    It has been quite a time since the last public news ; we will try in the letter to summarize what we did during february and march 2021. During this period, we tried to fix issues, migrate a lot of our code base to latest version of CubicWeb. We also did some archeology ; we have been looking at all the old heads in CubicWeb's repository, and we have tried to rebase them on the latest public head. A lot of merge requests have been created and are still under review.

    CubicWeb 3.30 is out!

    We released Cubicweb 3.30 on march 16th. There are no “big” changes in this release. A lot of issues have been fixed, the documentation have been improved − a new tuto is coming ! − and a few new features have been implemented.

    Here is an extract of the changelog:

    • it is now possible to use smtp authentification to send an email (#221)
    • required variables can be read from the environment (#85)
    • one can specify scripts attributes when using the add_js function (#210)
    • GROUP_CONCAT was not returning the expected results when NULL values were encountered (#109)
    • it is now possible not to drop table indexes when using the MassiveStore (#219)

    One can find the full changelog on Cubicweb release page here.

    Adding python types to RQL

    In the past months, python types have progressively been included in RQL. This is a step forward to python types in CubicWeb itself.

    A lot of work has been done, and there is still a lot of work to do. Adding types to RQL help us to simplify the refactorings. As RQL's API is not clearly defined, we will run CubicWeb's tests on each merge request of RQL, to make sure nothing breaks.

    Separate Back and Front

    For some time now, the trend has been towards a clear separation between front and back. We are adding more features to use React in the front.

    CwClientLibJS, a library allowing to use rql in the browser. CwClientLibJS is now in version 1.1.0 and is able to generate query on entity state (see !20).

    react-admin-cubicweb, new tools to generate admin pages. react-admin-cubicweb is still at an early stage but can display entity attribute and relation. It also allows edition as well. The version 0.3.0 has been released !

    Release-new

    Release-new is one of our latest utility to release new versions of our cubes. Assuming that you are using conventional commits, you should really like this tool to release new version of your cubes.

    Release-new takes care to:

    • update the version of the cube in __pkginfo__.py
    • update the debian/control if there is one
    • update the changelog
    • create a new commit with theses changes
    • tag the commit

    By default, it will try to guess if it is a major, minor or patch release (you can specify the release type if need be). The changelog will be updated and you will be able to edit it before the commit is done. The update of the changelog will be eased if you use conventionnal commit as your commit history will be dispatched in the appropriate sections. For instance, the last changelog of CubicWeb has been produced by this tool !

    Docker images

    During our last hackathon, a team worked on our CubicWeb Docker images. The code to generate them has been rewritten to be simpler. During this refactoring, we took care to generate docker images for minor versions of CubicWeb as well. Therefore, on https://hub.docker.com/r/logilab/cubicweb/tags you can find docker images for major and minor versions of CubicWeb with different versions of python, to suit your needs the best we can :)

    See you next month!


  • CubicWeb Monthly news january 2021

    2021/02/10 by Fabien Amarger

    New organisation

    For this new year, we decided to change how we organise the CubicWeb project at Logilab. We clarified how to define priorities and how to contribute.

    Rotating the coordinator of the month

    First of all, we pinpointed the need to have a coordinator to organise meetings, issues and dispatch work between contributors. It was an evidence to define this role as a rotating responsability. Each month a coordinator is picked from the volontary participants. The previous coordinator and the new one have to write this monthly review together to communicate on what happened for the CubicWeb project during the month and to officially change the coordinator.

    New kanban boards

    To separate the on-going issues and the planned issues for the next versions, we divided the existing kanban in two.

    The first one defines the ongoing work and the states of each issue. The column "IMPORTANT" is used to track the important bug which need to be fixed in the version in development.

    The R&D board tracks the ideas and the future versions. This board contains an "IDEA" column, which is used as a backlog. Then we can move the "IDEA" issues into the dedicated column to plan the issue for a specific future version. The "Exploration" label is set on issues that are not asking to implement a feature, but to explore the problem and find a good implementation plan. Ideally these issues will lead to classic issues to be implemented.

    The CubicWeb Forge is dead, Heptapod is our new friend

    After months in transition, we decided to announce that the official site to develop CubicWeb is Logilab's Heptapod instance in replacement of the CubicWeb Forge.

    Heptapod is a friendly fork of GitLab that supports Mercurial repositories, allowing to use all the features of GitLab and all the features of Mercurial (draft changesets, automatic evolution, etc).

    All cubes were migrated to the new forge. CubicWeb Forge is still available, but will be made read-only and will be shutdown in the future.

    Weekly meeting

    Every tuesday afternoon (UTC+1), there is a weekly meeting. We discuss the issues in the kanban boards to track progress and plan the work. Feel free to join us in the CubicWeb matrix room.

    CubicWeb sprint

    To work on specific issues we have decided to organize regular sprints. The first one occured on January 26th and 27th 2021 with ten participants. It was a success as good work was done.

    Separate Back and Front

    The main subject which was studied during this sprint was the front/back separation, which is an "Exploration" issue planned for the CubicWeb v3.30.

    CWClientLibJS

    We discussed improving CWClientLibJS to help JavaScript developers write RQL queries into the front application. We defined a draft API for the QueryBuilder class which will be used to write RQL queries into JavaScript codebase. This API will allow to write complex RQL queries easily, such as with optionnal parameters. And the YAMS schema will be used to add helpers to get entity from eid and to organize the RQL query response depending on the entity type attributes.

    The next steps will be to test this API into a project and study how to handle authentication.

    CWElements

    Another subject is how to generate frontend forms from the YAMS schema, such as the current CubicWeb.web implementation but all with the React framework. The result is implemented into the CWElements project: - handle relations - allow update queries.

    The ongoing issues for CWElements is to test this form into a project and define how to establish a graphical identity by specifying CSS files and/or CSS framework (such as Bootstrap, Material-UI and so on)

    Cleaning up the CubicWeb code repository

    We corrected some bugs listed below, but more importantly we transformed all the branches from the old forge into merge requests in the new forge. Each merge request will thus be properly tracked and reviewed.

    If you have a patch for CubicWeb, now is a good time to send a merge request. The merge requests will benefit from the automatimated tests. Also, all the discussion will be properly stored.

    Important issues closed and merged

    • [v3.30] [docker] allow to read REQUIRED variables from environments #85
    • [v3.30] remove statsd integration? #39
    • [v3.30] remove web.cors in favor of wsgicors with pyramid #192
    • [v3.30] RQL TODAY in sqlite is not equivalent to RQL TODAY in postgresql #109
    • [v3.30] Include pyramid as direct deps in cubicweb by default #191
    • [v3.26] Box view of a CWEtype is broken #74
    • [v3.26 & v3.30] No translation in pviews #87

    Documentation

    Since we started working on Cubicweb 3.29, we have been reworking the documentation step-by-step.

    A new landing page was created.

    A new tutorial is being written.

    It focus on:

    • Data import
    • React to display a custom page (with RQL information)
    • content-negociation to retrieve information in RDF format

    The fictionnal usecase is a website publishing a list of museum (imported from an existing source). The final result is compiled in the tuto cube.

    If you have any comment on the documentation, create an issue or come in the matrix room.


  • Report of June 16th Cubicweb Meeting

    2020/06/24 by Henri Cazottes

    Hi everyone,

    Here is the weekly report of last week meeting with some delay...

    Kanban status

    You can check the milestone here

    • Build the new cubicweb image for all the intranet apps on the public head #9
    • Add py{27,3}-from-forge to clients project to ensure we don't break everything when releasing #37
      • MR waiting on francearchive, Laurent is going to talk to Katia about it. Also Simon says that everything is fine with 3.28rc1 on data.bnf
      • all internal apps of logilab runs with 3.28rc1 and there is not bugs to signal

    Todo

    • Setup a demo with a SPARQL API
      • this work has been started few years ago but today clients are interested in this feature
      • option to create an RQL-SPARQL bridge would be too long
      • work in progress to compare RQL and SPARQL expressiveness, not done yet
      • current lead: using rdflib-sqlalchemy by adding tables next to existing Cubicweb tables and creating a prototype of an OWL to YAMS converter
    • Rollback class_deprecated modifications on logilab-common
    • Continue typing other libs such as:
      • cubicweb (complex)
      • rql
      • logilab-mtconverter
        • Patrick will probably start with this before continuing on RQL
      • logilab-constrain
      • logilab-database
    • Identify "good first issue" to ease contributing
    • Think about the documentation structure and what we want to write (for the next release)
      • reduce technical debt
      • spread documentation improvements among several sprints

    Current work

    • working on fixes for YAMS tip for CW
    • reducing the load on the CI by removing some useless tests when triggered from other CI
    • adding needed commits on https://github.com/logilab/yapps to update it for python3 compatibility

    See you very soon for the next report !


  • Report of June 10th Cubicweb Meeting

    2020/06/09 by Laurent Peuch

    Hi everyone,

    We've just published the RC1 for CubicWeb https://pypi.org/project/cubicweb/3.28.0rc1/ and a new version 1.7.0 for logilab-common https://pypi.org/project/logilab-common/1.7.0/

    Our current focus is finishing the last details for the release.

    Milestone update

    • the changelog is now part of the documentation of logilab-common to make sure it is visible
    • test our clients project against our latest version on our repository to ensure we don't break everything when making a release
    • allow 2 randomly breaking tests to fail (those aren't part of the code we are currently working on)

    Current roadmap

    Semver

    One of our focus right now is to make stable releases of our core projects that won't break all the things ™ and we've made a lot of improvement in our testing suit to ensure that we test everything against our latest modifications before a release is made. Another problem we have right now is that CW only depends on a minimum version number for its dependencies, this mean that if we want to make a new release for one of the dependencies that will have some breaking code this introduce the risk of breaking all new CW installations.

    To solve this situation we have decided to implement semantic versioning and only introduction breaking changes in major releases and in addition to only depends on one specific major release at the time in CW dependencies. This way, when we need to make a new release with breaking changes, this will be a major release and we won't break all new CW installations.

    We have planned to start implementing this strategy starting CW version 4.0

    Various updates

    • a lot of fixes have been pushed on YAMS and CubicWeb to make CubicWeb compatible with the latest modifications in YAMS

    See you next week!


  • Report of June 3rd Cubicweb Meeting

    2020/06/03 by Henri Cazottes

    Hi everyrone,

    Version 3.28-rc1 is on its way! First, let's have a look to the issue board state.

    Milestone update

    • Introduced types #10
      • logilab.common.deprecation has been typed (see hackathon report below): done
    • Add tests for the content negociation !20: MR about to be accepted
    • Update logilab-common changelogs #43 : done
    • Add automatic doc re-build to the CubicWeb CI #8 : done

    Todo

    • Review and accept MR !20
    • Release logilab-common and cubicweb 3.28-rc1

    Semver discussions

    Right now, dependencies are only specifying a minimal version. So if we introduce a breaking change in a new version, apps might break too. We plan to follow semver convention to prevent this from happening.

    We also discussed the idea of aligning version between compatible tools, so every major version would work with the same major version of other tools/dependencies.

    This idea will be introduced in 3.29 documentation, but will probably start with the release of Cubicweb version 4.

    Hackathon

    Last Friday we did an internal hackathon at Logilab and Laurent, Noé and I spent time working on Cubicweb. We mainly:

    • wrote changelogs for:
      • logilab-common
      • cubicweb
    • tried to add a Merge Request template on Cubicweb
      • doesn't work on Heptapod actually, we will ask Octobus to have a look (see #46)
    • added annotation types on logilab.common.deprecated
    • improved tox.ini and added a gitlag-ci.yaml file in cube skeleton

    That's all! You should receive and email soon about the rc1 release.

    Thanks for reading,

    Henri


  • Report of May 26th Cubicweb Meeting

    2020/05/26 by Henri Cazottes

    Hi,

    Welcome back to another weekly report! Today, the following topics have been discussed.

    Broken tests situation, follow up

    Migrating CubicWeb to Heptapod and modifications in dependencies resulted in broken tests as it was presented last week. Work has been done on Friday afternoon thanks to Simon and Laurent, but it's not fixed yet. Tox is now happy but we still have a bug on a test that succeeds locally but not when run by the CI job. We do have a lead which may concern firefox usage in headless mode. Jobs logs are available here.

    Milestone update

    • Introduced types
      • Types have been added in Yams, merge request about to be reviewed
      • We choose to dissociate this issue from the actual release as it's more related to Yams and not mandatory to release a 3.28 version.
      • Re-build ReadTheDoc for every release
      • Done for most of the dependencies but not CubicWeb yet
      • Two dependencies, mtconvert and constraint don't have doc nor tests, we think about removing them instead of creating and maintaining this code which is pretty old
    • Move to semantic versionning
      • we talked about improving dependencies requirements to ease the release process (not giving only one version)
      • we think we should stick to semver, but we need to discuss it more (should we bump all major version to the same number for interoperable dependencies, etc...)
      • As those questions need to be discussed, we choose to move this issue to the 3.29 milestone
    • Add tests to content negociation
      • Need to be done
    • Check if ?vid=rdf is still working
      • Done
      • We did spot that requesting vid=rdf or using content negotiation would not return the same RDF. We should fix this to have a more consistent behavior. Will be added for the next release.

    Todo before releasing version 3.28

    To sum up, before releasing the next CubicWeb version, we need to:

    • Fix CI tests
    • Add automatic doc re-build to the CubicWeb CI

    This should be done and released within the next two weeks.

    Side notes

    • For the next release we should align CubicWeb with changes made in Yams
    • Release early, release often

    See you next week!


  • Report of May 19th Cubicweb Meeting

    2020/05/20 by Simon Chabot

    Hi everyone,

    Yesterday we held a new CubicWeb meeting, and we would like to share with you what was said during that meeting :

    • some issues have been migrated from cubicweb.org forge to the heptapod forge. You can find them here. Only the issues which were in the cubicweb-dev-board have been migrated, the others have been considered too old to make their migration worthwhile ;

    • new milestones have been created, and some issues have been affected to them ;

    • if you want to help out with Cubicweb's development, you can have a look to the Issues Board, and pick one task in the “To Do” column (this task should be related to a milestone) ;

    • CW tests are still failing on the forge, and it's also related to other packages that have been released. Fixing those tests is quite urgent now, therefore we suggest to fix them in a sprint this Friday afternoon. Feel
      free to join !

    • On main Cubicweb's dependencies (RQL, YAMS, logilab-common, etc), a heptapod job has been added to trigger CW's tests with the last version of the dependency in the forge and not only the last released version on pypi. This should help to release new versions of CW's dependencies with
      more confidence. (for now, it only triggers the job, a future version of heptapod should provide a better integration of multi-project pipelines) ;

    • The documentations of CubicWeb's dependencies are now automatically published on readthedocs. The work is in progress for CubicWeb itself ;

    Next week, if the tests are successful, we will talk about a release candidate for 3.28.

    Stay tuned :)


  • A roadmap to Cubicweb 3.28 (and beyond)

    2020/05/13 by Simon Chabot

    Yesterday at Logilab we had a small meeting to discuss about a roadmap to Cubicweb 3.28 (and beyond), and we would like to report back to you from this meeting.

    Cubicweb 3.28 will mainly bring the implementation of content negotiation. It means that Cubicweb will handle content negotiation and will be able to return RDF using Cubicweb's ontology when requested by a client.

    The 3.28 will have other features as well (like a new variables attributes to ResultSet that contains the name of the projected variables, etc). Those features will be detailed the release changelog.

    Before releasing this version, we would like to finish the migration to heptapod, to make sure that everything is ok. The remaining tasks are:

    • fixing the CI (there is still some random failings, that need further investigation)
    • migrate the jenkins job that pushes images to hub.docker.com on heptapod, to make everthing available from the forge. It will be explicit for everyone when a job is done, and what is its status.

    Beside of releasing Cubicweb 3.28, its ecosystem will also be updated:

    • logilab-common, a new version will be released very soon, which brings a refactoring of the deprecation system, and annotations (coming from pyannotate)
    • yams, a new version is coming. This version:
    • brings type annotation (manually done, a carefully checked);
    • removes a lot of abbreviation to make the code clearer;
    • removes some magic related to a object which used to behave like a string;

    The goal of these two releases, is to have type annotations in the core libraries used by CubicWeb, and then to be able to bring type annotation into CubicWeb itself, in a future version.

    On those projects, some “modernisation” has been started too ; (fixing flake8 when needed, repaint the code black). This “modernisation” step is still on going on the different projects related to CubicWeb (and achieved for yams, and logilab-common).

    In the medium term, we would like to focus on the documentation of CubicWeb and its ecosystem. We do know that it's really hard for newcomers (and even ourself sometime) to understand how to start, what each module is doing etc. An automatic documentation has been released for some modules (see 1, 2 or 3 for instance). It would be nice to automatize the update of the documentation on readthedocs, update the old examples, and add new ones about the new feature we are adding (like content negotiation, pyramid predicates, etc). This could be done in team Friday's sprint or hackathon for instance. CubicWeb would also need some modernisation (running black ? and above all, make all files flake8 compilant…).

    Regarding CubicWeb development, all (or, at least a lot of) cubes and Cubicweb related projects moved from cubicweb.org's forge to our instance of heptapod (4 and 5). Some issues have been imported from cubicweb.org to heptapod. New issues should be opened on heptapod, and the review should also be done there. We hope that will ease the reappropriation of the code basis and stimulates new merge-requests :)

    To end this report, we like to emphasis that we will try to make a « remote Cubicweb meeting » each Tuesday at 2 pm. If you would like to participate to this meeting, it's with great pleasure (if you need the webconference URL, contact one of us, we will provide it to you). We also created a #Cubicweb channel on matrix.logilab.org ; feel free to ask for an invitation if you'd like to discuss Cubicweb related things with us.

    All the best, and… see you next Tuesday :)


  • What is new in CubicWeb 3.27 ?

    2020/02/03 by Nicolas Chauvat

    Hello CubicWeb community,

    We are pleased to announce the release of CubicWeb 3.27. Many thanks to all the contributors of this release!

    Main changes in this release are listed below. Please note this release drops python2 support.

    Enjoy this new version!

    New features

    • Tests can now be run concurrently across multiple processes. You can use pytest-xdist for that. For tests using PostgresApptestConfiguration you should be aware that startpgcluster() can't run concurrently. Workaround is to call pytest with --dist=loadfile to use a single test process per test module or use an existing database cluster and set db-host and db-port of devtools.DEFAULT_PSQL_SOURCES['system'] accordingly.
    • on cubicweb-ctl create and cubicweb-ctl pyramid, if it doesn't already exist in the instance directory, the pyramid.ini file will be generated with the needed secrets.
    • add a --pdb flag to all cubicweb-ctl command to launch (i)pdb if an exception occurs during a command execution.
    • the --loglevel and --dbglevel flags are available for all cubicweb-ctl instance commands (and not only the pyramid one)
    • following "only in foreground" behavior all commands logs to stdout by default from now on. To still log to a file pass log_to_file=True to CubicWebConfiguration.config_for
    • add a new migration function update_bfss_path(old_path, new_path) to update the path in Bytes File-System Storage (bfss).
    • on every request display request path and selected controller in CLI
    • migration interactive mode improvements:
      • when an exception occurs, display the full traceback instead of only the exception
      • on migration p(db) choice, launch ipdb if it's installed
      • on migration p(db) choice, give the traceback to pdb if it's available, this mean that the (i)pdb interactive session will be on the stack of the exception instead of being on the stack where pdb is launched which will allow the user to access all the relevant context of the exception which otherwise is lost
    • on DBG_SQL and/or DBG_RQL, if pygments is installed, syntax highlight sql/rql debug output
    • allow to specify the instance id for any instance command using the CW_INSTANCE global variable instead of or giving it as a cli argument
    • when debugmode is activated ('-D/--debug' on the pyramid command for example), the HTML generated by CW will contains new tags that will indicate by which object in the code it has been generated and in which line of which source code. For example:
    <div
      cubicweb-generated-by="cubicweb.web.views.basetemplates.TheMainTemplate"
      cubicweb-from-source="/home/user/code/logilab/cubicweb/cubicweb/web/views/basetemplates.py:161"
      id="contentmain">
        <h1
          cubicweb-generated-by="cubicweb.web.views.basetemplates.TheMainTemplate"
          cubicweb-from-source="/home/user/code/logilab/cubicweb/cubicweb/view.py:136">
            unset title
        </h1>
        [...]
    </div>
    

    While this hasn't been done yet, this feature is an open path for building dynamic tools that can help inspect the page.

    • a new debug channels mechanism has been added, you can subscribe to one of those channels in your python code to build debug tools for example (the pyramid custom panels are built using that) and you will receive a datastructure (a dict) containing related information. The available channels are: controller, rql, sql, vreg, registry_decisions
    • add a new '-t/--toolbar' option the pyramid command to activate the pyramid debugtoolbar
    • a series of pyramid debugtoolbar panels specifically made for CW, see bellow

    Pyramid debugtoolbar and custom panel

    The pyramid debugtoolbar is now integrated into CubicWeb during the development phase when you use the 'pyramid' command. To activate it you need to pass the '-t/--toolbar' argument to the 'pyramid' command.

    In addition, a series of custom panels specifically done for CW are now available, they display useful information for the development and the debugging of each page. The available panels are:

    • a general panel which contains the selected controller, the current settings and useful links screenshot1
    • a panel listing all decisions taken in registry for building this page screenshot2
    • a panel listing the content of the vreg registries screenshot3
    • a panel listing all the RQL queries made during a request screenshot4
    • a panel listing all the SQL queries made during a request screenshot5

    Furthermore, in all those panels, next to each object/class/function/method a link to display its source code is available (shown as '[source]' screenshot6) and also every file path shown is a traceback is also a link to display the corresponding file (screenshot7). For example: screenshot8.

    Backwards incompatible changes

    • Standardization on the way to launch a cubicweb instance, from now on the only way to do that will be the used the pyramid command. Therefore:

      • cubicweb-ctl commands "start", "stop", "restart", "reload" and "status" have been removed because they relied on the Twisted web server backend that is no longer maintained nor working with Python 3.
      • Twisted web server support has been removed.
      • cubicweb-ctl wsgi has also been removed.
    • Support for legacy cubes (in the 'cubes' python namespace) has been dropped. Use of environment variables CW_CUBES_PATH and CUBES_DIR is removed.

    • Python 2 support has been dropped.

    • Exceptions in notification hooks aren't catched-all anymore during tests so one can expect tests that seem to pass (but were actually silently failing) to fail now.

    • All "cubicweb-ctl" command only accept one instance argument from now one (instead of 0 to n)

    • 'pyramid' command will always run in the foreground now, by consequence the option --no-daemon has been removed.

    • DBG_MS flag has been removed since it is not used anymore

    • transactions db logs where displayed using the logging (debug/info/warning...) mechanism, now it is only displayed if the corresponding DBG_OPS flag is used

    Deprecated code drops

    Most code deprecated by version 3.25 or older versions has been dropped.


show 144 results