We have an official account on NPM [1] and the associated org [2] (cc @Mark Thomas <ma...@apache.org> IIRC who manages this account).
[1] https://www.npmjs.com/~theasf [2] https://www.npmjs.com/org/apache Both of these associations can improve the verification and brand for your release, while you may use the @apache scope in your package's name to replace the handy apache- prefix that isn't endorsed by NPM's mechanism. For the name and branding topic, I would suggest (in priority): 1. State your display name as Apache KIE™ (incubating) on the release page (README). 2. Build an association with our official NPM organization, following NPM's mechanism. 3. Change your package name (handle) to @apache/kie-xxx. As for the VS Code Extensions, I'm unfamiliar with this scope, but it seems there are other names like "kogito". What are the relations between them and KIE? As for the WebJar, I'm unfamiliar with this scope also. And I don't find an entry called sonataflow-deployment-webapp on the page you linked. The official name of an ASF project is always Apache Foo [3], and we should use this name when possible. [3] https://www.apache.org/foundation/marks/guide Best, tison. Tiago Bento <tiagobe...@apache.org> 于2024年5月16日周四 00:43写道： > Shawn, > > Does that mean you didn't publish anything to NPM as part of your > releases while in the incubator? > > On Wed, May 15, 2024 at 12:31 PM Shawn Yang <shawn.ck.y...@gmail.com> > wrote: > > > > Hi Tiago, > > > > From the current incubator release policy, you need to rename all npm > > packages to apache-xxx before releasing. The packages released before > > should be on to left intact. > > > > I came across same issue when we release apache fury. In your case, most > > packages starts with kie. Fury has similar rules which starts with > furyjs. > > Rename to apache-xxx has many works to do and breaks the compatibility > with > > downstreams. So fury just skipped release binary packages for fury > > JavaScript. > > > > I was wondering whether the incubator release policy remove such name > > rules. It does introduce extra work and confusion to podlings. And It's > not > > idiomatic in npm. Similar confusion exists for Python wheels. In Python, > > the naming needs to be consise and be as short as possible. We barely > see a > > wheel in a organization name wheel as $orgname-xxx. > > > > > > > > On Wednesday, May 15, 2024, Tiago Bento <tiagobe...@apache.org> wrote: > > > > > Hi general@incubator, > > > > > > The distribution guidelines [1] say packages published to NPM should > > > be named `apache-<package>`, however, at KIE, we have a somewhat big > > > set of packages that are published under these scopes: > > > - @kie-tools/* > > > - @kie-tools-core/* > > > - @kie-tools-scripts/* > > > > > > There are also some VS Code Extensions (which can't have a scope): > > > - yard-vscode-extension > > > - swf-vscode-extension > > > - pmml-vscode-extension > > > - dmn-vscode-extension > > > - bpmn-vscode-extension > > > - vscode-extension-kogito-bundle > > > - vscode-extension-kie-ba-bundle > > > - vscode-extension-dashbuilder-editor > > > > > > And a one-off package that is later then transformed into a Maven > > > WebJar [2] (which can't have a scope either) > > > - sonataflow-deployment-webapp > > > > > > Those do not conform with the guidelines, but have been published > > > under these scopes/names for quite some time now, before KIE became a > > > podling. > > > > > > My question is: Are we required to rename everything prior to > > > releasing? Or are we able to pass a vote with the current package > > > names? Asking because that's a substantial amount of work prior to > > > releasing, and also because renaming everything would mean consumers > > > would have to manually "migrate" to the new package names. > > > > > > Thanks a lot in advance! > > > > > > Regards, > > > > > > Tiago Bento > > > > > > > > > [1] https://incubator.apache.org/guides/distribution.html#npm > > > [2] https://www.webjars.org/ > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > > For additional commands, e-mail: general-h...@incubator.apache.org > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
