Hi Tiago, > How? Every package we ever published to NPM under KIE is owned by > https://www.npmjs.com/~kie-tools-bot now (some of them were > removed/renamed). We can give control to the ~theasf user, no problem.
You can open an INFRA JIRA ticket like [1]. [1] https://issues.apache.org/jira/browse/INFRA-25325 > if this could be postponed to the next release, it would be great. I listed the suggestion in priority (desc order), so it's OK that your first release keeps this @kie namespace, especially since Kie's trademark is (to be) transferred to the ASF. However, @apache/kie-xxx is more appropriate and I'll appreciate it if you can arrive there in the following releases. You may think of ASF Java packages that are released with org.apache.<project> group id. I hope the NPM scope is the idiom that accomplishes the same thing on that platform. > Renaming it would mean essentially creating new extensions, without any relationship to the old ones whatsoever. >From my experience using VS Code extensions, it should be possible to deprecate the old extension and suggest a successor extension in the README. If you'd release those VS Code extensions under the existing name for now, I'd suggest the following things to improve: 1. State the relationship between the extension and Apache KIE™ (Incubating) in the README. 2. Update the description and the display name of the owner account "KIE" [2]. I may prefer to work with ASF INFRA to register an official ASF account to own these extensions, but the INFRA team may have a different opinion since they may not manage all the accounts among all release channels. You should try to reach out to them. [2] https://marketplace.visualstudio.com/publishers/kie-group To be clear, these are the first few improvement items that came to mind. But they may not be all you can or should do. > If you type "sonataflow" in the search input at the right-hand-side > you'll see that a JAR was published based on the NPM package. See I think it's generally possible to move the group ID to org.apache.kie. Best, tison. Tiago Bento <tiagobe...@apache.org> 于2024年5月17日周五 03:55写道： > Thanks all for the replies. > > I'll try to postpone renaming the packages we have today, so we'll > start the release vote without this renaming. All packages will > include the DISCLAIMER in their README files. E.g., > > https://github.com/apache/incubator-kie-tools/blob/main/packages/dmn-editor/README.md > > I hope that's ok for a first incubator release. We'll address any > feedback we receive on the voting thread. > > Of course, for the next release I'll have a plan for renaming all > Apache KIE (incubating) NPM packages and for publishing them under > ~theasf, and @apache or @apache-kie scopes. > > Thanks again for your input. > > Regards, > > Tiago Bento > > On Wed, May 15, 2024 at 4:36 PM Dave Fisher <w...@apache.org> wrote: > > > > Here’s my 2 cents. > > > > Incubation is a journey, and if there are parts that are yet to be > compliant that should be fine. In the end all will be squared away. > > > > For the IPMC - should we have something like DISCLAIMER-WIP for binary > convenience packaging? > > > > Best, > > Dave > > > > > On May 15, 2024, at 1:13 PM, Tiago Bento <tiagobe...@apache.org> > wrote: > > > > > > Tison, > > > > > > Thanks for the reply! > > > > > > On Wed, May 15, 2024 at 1:43 PM tison <wander4...@gmail.com <mailto: > wander4...@gmail.com>> wrote: > > >> > > >> 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). > > > Ok. > > > > > >> 2. Build an association with our official NPM organization, following > NPM's > > >> mechanism. > > > How? Every package we ever published to NPM under KIE is owned by > > > https://www.npmjs.com/~kie-tools-bot < > https://www.npmjs.com/~kie-tools-bot> now (some of them were > > > removed/renamed). We can give control to the ~theasf user, no problem. > > > > > >> 3. Change your package name (handle) to @apache/kie-xxx. > > > This is what I'd like to avoid, as it's going to be major work on our > > > side due to the number of packages we have, delaying our release even > > > more... I see OpenDAL has some packages published under the `opendal` > > > and `@opendal/*` names, which is kind of analogous to what we'd have > > > without renaming. Of course we can move everything to @apache/kie-* or > > > @apache-kie/* to comply with the guidelines and requirements, but if > > > this could be postponed to the next release, it would be great. > > >> > > >> 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? > > > Drools, jBPM, SonataFlow, OptaPlanner, Kogito, and Tools are all > > > components inside KIE. All KIE VS Code Extensions are already > > > published under these names I listed. Renaming it would mean > > > essentially creating new extensions, without any relationship to the > > > old ones whatsoever. Example: > > > > https://marketplace.visualstudio.com/items?itemName=kie-group.dmn-vscode-extension > < > https://marketplace.visualstudio.com/items?itemName=kie-group.dmn-vscode-extension > > > > > > > >> > > >> 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. > > > If you type "sonataflow" in the search input at the right-hand-side > > > you'll see that a JAR was published based on the NPM package. See > > > > https://central.sonatype.com/artifact/org.webjars.npm/sonataflow-deployment-webapp > < > https://central.sonatype.com/artifact/org.webjars.npm/sonataflow-deployment-webapp > > > > > > > >> > > >> The official name of an ASF project is always Apache Foo [3], and we > should > > >> use this name when possible. > > > Ok. > > > > > >> > > >> [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 > > >>> > > >>> > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > <mailto:general-unsubscr...@incubator.apache.org> > > > For additional commands, e-mail: general-h...@incubator.apache.org > <mailto:general-h...@incubator.apache.org> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
