When will be the next stable release?

[panda-byte]

I'm a bit confused about the current state of NGL. According to GitHub, the latest release is v0.9.3 from 15 Oct 2016, while the version delivered by the unpkg CDN described in the manual is 0.10.4, and so is the current npm package as described by the docs. #384 is about the 1.0 release, which according to GitHub, has never been reached. However, version 2.0.0 seems to have been in development for some time now.

My question is basically: should/can I use a version upwards of 0.10.4 for deployment, and the docs / GitHub releases just were never updated? Or is 0.10.4 indeed still the version intended for deployment? In any case, maybe a clarifying statement somewhere in the manual, the docs or in the GitHub ReadMe would be helpful.

[fredludlow]

We should make a 2.0.0 release.

For now, you can install using either a specific version "2.0.0-dev.39" is most recent. Or npm i ngl@next

Others: Shall we just make current master 2.0.0? It's way overdue, I think I have the necessary permissions on npm to do it.

[panda-byte]

Oh, another thing concerning versions: the official online reference is currently at version 1.0.0-beta.7, it appears.

[fredludlow]

Have just released 2.0.0-dev.40.

Shall I just make this the proper 2.0.0 release with the @latest tag?

Building docs broke with typedoc update (required because of typescript update), I expect it's easy enough to fix...

[ppillot]

Maybe we should solve the issue of declarations distribution for this release?

Le 16 mars 2022 à 12:52, Fred Ludlow @.***> a écrit :

 Have just released 2.0.0-dev.40.

Shall I just make this the proper 2.0.0 release with the @latest tag?

Building docs broke with typedoc update (required because of typescript update), I expect it's easy enough to fix...

— Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you are subscribed to this thread.

[fredludlow]

Good idea - what's outstanding on this?

I have a (very) minimal demo for using it from a JS project: https://github.com/fredludlow/ngl-module-test which took a bit of fiddling just now to get back in a working state - it might be nice to do something similar with a barebones typescript project that imports NGL, with types exposed properly?

[ppillot]

I think we should at least ship the /declarations/ folder in the /dist/ folder. And test... Agreed about the ts example. I've tried to write one some time ago but did not reach something proper. There is also the possibility to leverage the declarations in JS projects through the JSDoc annotations.

[fredludlow]

The declarations folder is getting shipped in the current build, and the package.json has a "types" attribute that links to: e.g. https://unpkg.com/browse/[email protected]/dist/declarations/ngl.d.ts

(You can browse the shipped package here https://unpkg.com/browse/[email protected]/ )

What else would we need?

[fredludlow]

As an aside, we currently ship an esm.js file (referenced in "module" from package.json). That has dependencies on some non-es-module formatted modules (signals and chroma I think), which means downstream projects need to support resolving them somehow,

For rollup that's just using @rollup/plugin-commonjs: https://github.com/fredludlow/ngl-module-test/blob/master/rollup.config.js

It is, however, slightly annoying to force that complexity/dependency on consumers. I'm not really sure how to fix this other than moving them to devDependencies and making sure the code gets included in the various builds. The downside of this is possible duplication of code in downstream projects - they might include both our vendored-in signals and their own copy from an explicit dependency or a sub-dependency of another package.

[fredludlow]

I made an equivalent typescript minimal demo. Opening this in VSCode I get all the nice hover-over typing information that's being picked up from the type declarations:

https://github.com/fredludlow/ngl-ts-demo/tree/main

[ppillot]

I've just tested it, it works beautifully! Very cool! As far as I'm concerned it looks fine for shipping the 2.0 version

As for the dependencies, right, it's a limitation. Signal is quite small, but chroma is another story. I suppose we should recommend using a bundler. Another option would be to have the code directly frozen in NGL as is the case for the mmtf code, and was the case for three.js. It's tedious to do and won't address the code duplication issue you were mentioning.

[panda-byte]

Codecov Report

Merging #508 (e96bd58) into master (8e1cc27) will increase coverage by 0.00%. The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #508   +/-   ##
=======================================
  Coverage   50.19%   50.19%           
=======================================
  Files         120      120           
  Lines       28019    28019           
  Branches     2987     2987           
=======================================
+ Hits        14063    14064    +1     
  Misses      13489    13489           
+ Partials      467      466    -1     

Impacted Files	Coverage Δ
fury/fury/stream/tools.py	91.15% <0.00%> (+0.21%)	:arrow_up:

[galeo]

Hi @fredludlow

I see the latest tagged version is v2.0.0. But the latest installed version is still v2.0.0-dev.40. Will version 2.0.0 be released? And when?

Thanks.

[panda-byte]

It would be great if the tagged version v2.0.0 was available on unpkg.

[fredludlow]

I've published 2.0.1 - let me know how it goes