Deployment workflows

[cboulanger]

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?

[hkollmann]

a) I would prefer the source in the package - so you have an consistence state. We should put the courrent source tree of the framework into the compiler before packing him.
b) The framework package is only needed for old projects, And the older compiler version. IMHO it must'nt be maintained and could be set to deprecated for v7.

[johnspackman]

I don't agree, IMHO the framework source code should be a npm package because the framework is not really tied to the compiler in that way. As the compiler is installed by npm, there shouldn't be any version issues and it keeps things clean and explicable. The compiler version numbers do not match with the framework version numbers either, so if we ship the source code of the framework with the compiler, we'll have to "know" that if you're using compiler v1.2.3 that this relates to framework version 6.2.1

Having the framework as an independent version allows users to easily choose a specific framework version (eg for team development), and be clear about exactly what version of the framework they are all using. It makes sense for this to be independent of compiler version, because a minor bugfix or feature improvement in the tooling should not force everyone in the team to upgrade their framework - not least because they might be concerned that there is a lot more room for problems to be introduced if the whole framework is upgraded.

There are two variants of entire-framework-as-a-single-js-file that we would want to produce - one for browser development and one for nodejs development. The browser version should only be made available via a CDN - it's only used for browser apps which have no compiler and therefore no loader, and while there are some webpack-type tools which pull in JS from npm, there are plenty of those tools which do not use npm. All tools, including projects which do not use tools like jsfiddle, will support CDN versions so it's an easy fix. (Also, the browser version of entire-framework-as-a-single-js-file is not the same as the framework shipped as npm that I mentioned in the first paragraph)

The nodejs version of entire-framework-as-a-single-js-file would obviously only have an npm version.

[cboulanger]

I agree with John that it makes sense to keep compiler and framework separate as NPM packages, at least for the time being. We should revisit this question when we start v7. We've always talked about re-integrating the qx.tool namespace back into the main code tree, but that's a decision we should consider thoroughly, since there are some practical reasons to keep them separate. Anyways, that's for later.

If we can agree to this, at least temporarily, would this be the list of deliverables?

1. NPM: Compiled compiler
2. NPM: Framework source code
3. CDN package (entire-framework-as-a-single-js-file)
4. NPM "Qx-Server" (entire-server-framework-as-single-file)
   • containing the compiler or not (probably not)?
   • part of 2. (as it is now) or separate (which I would prefer)?

[hkollmann]

I agree too.

4. seperate module. We had this before: https://www.npmjs.com/package/qooxdoo-sdk

[johnspackman]

👍 #4 not including the compiler

[cboulanger]

Ok, we seem to have a consensus. I'll post it on the dev chat to give the others the opportunity to weigh in.

[cboulanger]

• NPM package @qooxdoo/framework: uncompiled framework source code with no dependencies, just the raw framework code
• NPM package @qooxdoo/compiler: as before, but in compiled form (single file), with dependency on 1.
• NPM package @qooxdoo/server: All classes that can run on the server except the qx.tool namespace, in compiled form as one file.
• CDN package of the entire framework as one single JS-file, except classes that are not needed or don't run in the browser (such as qx.test or qx.tool namespaces).

[cboulanger]

The old https://www.npmjs.com/package/qooxdoo package should probably be a copy of @qooxdoo/server.

[oetiker]

in the past there where several changes to the framework which also required changes to the compiler ... effectively tying the two together ... when doing the theming work I was looking at adding additional features to the theme definition method and found that this is not easily possible without changing the compiler as the compiler knows which properties are legal in a theme definition ...

how do we deal with this ?

[cboulanger]

@oetiker I think this needs to be dealt with on the level of the application, which can enforce a minimal version of both compiler and framework. As I've said above, we should think about the pros and cons of one single codebase for compiler and framework, but I think the right time for this is after the release of v6.

[johnspackman]

I was looking at adding additional features to the theme definition method and found that this is not easily possible without changing the compiler as the compiler knows which properties are legal

I think that this is a bit of a special case - the compiler tends to care little about many of the keys, but does try to expect certain keys just so that it can provide warnings or errors at compile time instead of leaving it until runtime; AFAICR the generator did a similar thing, although the generator was better at policing it than the compiler is.

[cboulanger]

In @qooxdoo/server, should we ship two different packages, one for current node LTS and one for Rhino? They certainly would have different babel settings. Or is Rhino such a special case that we leave it to users to hand-compile a Rhino version (I think among us, only @johnspackman uses it). UPDATE: Or should it be a least-common-denominator build?

[johnspackman]

NodeJS only, because Rhino does not have a delivery mechanism or even require (and you might well be right that I'm the only Rhino user).

[hkollmann]

Which CDN server we should use?
This is the not longer supported web pack: https://www.cdnpkg.com/qooxdoo?id=63524

[cboulanger]

I don't know. What do the cool kids use these days? cdnpkg looks ok to me...