qooxdoo / deployment

In this repository, we run tests and deploy the qooxdoo NPM compiler and framework packages

Qooxdoo JavaScript Framework

qooxdoo is a universal JavaScript framework that enables you to create applications for a wide range of platforms. With its object-oriented programming model you build rich, interactive applications (RIAs), native-like apps for mobile devices, light-weight traditional web applications or even applications to run outside the browser.

You leverage its integrated tool chain to develop and deploy applications of any scale, while taking advantage of modern web technologies like HTML5 and CSS3, its comprehensive feature set and a state-of-the-art GUI toolkit. qooxdoo is open source under liberal licenses, led by a dedicated developer team, with a vibrant community.

For more information please see http://qooxdoo.org .

License

qooxdoo may be used under the terms of the MIT License.

Quick start

It is easy to get started with qooxdoo. For detailed information please see our Get Started Guide.

Documentation

• released version: https://qooxdoo.org/documentation/

API Ref

• released version: https://qooxdoo.org/qxl.apiviewer/

Development

If you develop with qooxdoo, you would normally use a stable NPM release, which, since v6.0.0, contains the compiler and the CLI called with with npx qx <command>.

In contrast, if you want to be hacking qooxdoo itself, please refer to our documentation.

Contributing

There are many ways you can contribute to qooxdoo, ranging from providing feedback, making translations, providing a custom library to full-blown patches to the code. Please check our web site for details. Mind that for every patch to the repository we require an open bug in our issue tracker, and that commits to the repository will fall under qooxdoo's license terms.

Qooxdoo source code is hosted on github/qooxdoo and we use the standard Issue Tracker and Pull Requests feature.

Community

Online chat is available via Gitter at https://gitter.im/qooxdoo/qooxdoo (or using one of the Gitter desktop or mobile clients) - the core team hang out there, as do other developers who use Qooxdoo.

Learn more

• Documentation

  • http://qooxdoo.org/documentation (latest stable)
  • http://qooxdoo.org/qooxdoo (current master)

• Online Demos http://qooxdoo.org/demos

• API Documentation http://qooxdoo.org/api

deployment's Issues

Deployment process

1. checkout qooxdoo repo
2. checkout compiler repo
3. mount framework dir into compiler node_modules/@qooxdoo/framework/source
4. compile the compiler
5. run compiler tests
6. link the compiler to $WORKING_ABS_DIR/bin/qx
7. compile the server framework with the new compiled compiler.
8. checkout apiviewer
9. compile apiviewer
10. run tests with apiviewer
11. do step 7 to 9 with each pkg we like
12. generate version number for framework
13. compile framework
14. publish NPM package @qooxdoo/framework
15. publish NPM package @qooxdoo/server
16. publish CDN package qooxdoo.
17. generate version number for the compiler
18. remove devDependencies from compiler package.json to avoid circular reference to @qooxdoo/compiler
19. add framework version number to @qooxdoo/framework dependency
20. publish NPM package @qooxdoo/compiler

Wrong version in compiler Manifest.json

The info.version key in the compiler's Manifest.json doesn't seem to get updated before NPM release. For example, in the current NPM module v1.0.0-beta-20200928-1855, the version info in the Manifest is "version": "1.0.0-beta-20200812-2003".

There is code to update the Manifest file but somehow this doesn't seem to work.

Any idea, @johnspackman , why this might be?

Deployment workflows

Here's how I understood our recent discussions:

In the deployment repo, we do the testing with the setup that John has already prepared (testing compiler with framework and framework with compiler, testing compiler and framework on a set of applications).

When building and testing are successful, we then release:

a) the compiler package, containing the compiled compiler, with a dependency on the framework package. However, the dependency is only on the framework source code. Because compiling takes place outside of the repo itself, we no longer have a circular dependency on the "qx_server" package. The source code could theoretically be downloaded on-the-fly from GitHub, or shipped with the compiler package (which would blow up its size). The dependency on the framework package mainly serves to keep the package size smaller.

b) the framework package, containing the uncompiled framework source code with a compiled version of qx_server. This package has no dependencies.

open questions:

• Should we release an all-inclusive qooxdoo compilation (the complete framework) to be released as an asset on GitHub and uploaded to a CDN (this has been requested many times).
• Updated The current Travis Job is limited to buiding and deploying the SDK to GitHub as long as we maintain the v6 line. Starting with v7, support for a SDK package will be dropped, since the NPM packages have taken over its function.

Is this the way to go?