Thanks for the additional information, Tison! Really appreciate it. Certainly right after the release this will be a top priority for me. The Apache KIE project publishes a lot of artifacts to a lot of different places, so this is all a little bit overwhelming to do for a first release. I'm glad the incubator allows for it to be done at a slower pace.
I already adjusted the names of all our VS Code and Chrome extensions, and they all will contain a DISCLAIMER at the end of their descriptions. The publisher names will change from "KIE" to "Apache KIE™ (incubating)", and point to https://kie.apache.org/. The WebJar's groupId unfortunately is not something we can change, as the "WebJars" project is an automated thing that will take packages from NPM and publish them to Maven. I guess for the next releases we can either 1) Stop using this "WebJars" mechanism altogether and publish a regular jar; or 2) Change our NPM package name to "apache-kie-sonataflow-deployment-webapp" (Can't use scopes on this one). This would produce the "org.webjars.npm:apache-kie-sonataflow-deployment-webapp:[version]" GAV. I'd rather do option 1, though. As for the VS Code Extensions themselves, absolutely we can use this deprecation strategy. It's a shame we'll lose the download counts (again), as these extensions started being published by Red Hat, then moved to KIE, and now are moving to Apache :) Nothing that a good README and nice deprecation messages can't help solve, though, I hope. Regarding the NPM packages, I guess that @apache/kie-*, @apache-kie/*, or apache-kie-* all are idiomatic enough. It's a common thing that projects start from an "unscopped" name to later on have a lot of packages and therefore start using a scope. Since we already have a fair amount of them, I guess we can really take advantage of the scopes from the beginning, except for those package that absolutely can't have a scope, like VS Code Extensions. Sorry for the lengthy email, and thanks again for the messages you sent. Really helped build our confidence in going for a first release. Regards, Tiago Bento On Thu, May 16, 2024 at 5:42 PM tison <wander4...@gmail.com> wrote: > > 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 > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
