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>
