OK, I changed my point-of-view on this topic and will close the discussion as `not-to-fix`.
We don't need to deprecate any NPM package. I have looked at a few major projects and almost all of them have never deprecated a package. Only a few projects use heavily used the `npm deprecate` command, but I think we don't need to manage this process. Node for example had never deprecated a package. NPM had deprecated two versions, 5 years ago but never since. I even glanced at a package where 120,000 other packages relies on it, and they have never deprecated a package. This package is known to sometimes cause NPM audit warnings/issues and those versions that caused the warnings were deprecated. The package's change logs even reported a few versions being corrupted and that users should update to a more recent version. Those corrupted versions were not deprecated. From what I am seeing, I think that no one uses the `npm deprecate` command nor wants to manage this type of process. They all might believe that a new release means that the previous versions are deprecated. Almost to a point where NPM could just remove this feature as useless. Better to not increase our process in this case. > On Aug 24, 2020, at 1:44, Jesse <purplecabb...@gmail.com> wrote: > > Where did this land? > > So, agreed, you did not say to deprecate minor, I meant to say we should > not deprecate any minor OR patch ... > If someone has an issue with a patch, the solution is always just to move > forward to the latest patch ... there is no 'support' expectation > Patching a patch would never make sense anyway, the patch version would > always get bumped anyway, so I see no need to deprecate patches. > > I also think we should be careful when we talk about 'support', or what 'we > support'. We do not have a service level agreement, or any support > contract, we do what we can with the time that we have ... To this reality, > strictly stating what we will or won't support does not make a ton of sense > to me. If someone sends a pr to backport a bug fix to a previous (implied > deprecated) version, we would probably just go and release it, because > someone wanted it ... and went and did it. > > I am good with deprecating the packages you listed, in the case of `Cordova > CLI 0.0.1`, it is equivalent to deprecating cordova@0.x > > > On Tue, Aug 18, 2020 at 6:56 PM Bryan Ellis <er...@apache.org> wrote: > >>>> I think this stance is too aggressive. >>>> For minor version bumps there is no need to deprecate the previous minor >>>> as any support request should be met with ‘update’ >> >> I also did not say to deprecate a minor. >> >>> When releasing a minor, nothing happens. >> >> Minors are typically just a new feature release. We should be able to >> support the existing minor and new minor. The only difference is one gets a >> new feature or not. >> >> I think deprecating at the patch level is the most important rule. For >> example, if 1.0.1 is released, 1.0.0 should be deprecated. Patches, for the >> most part, should contain only bug and security fixes. Users should upgrade >> the patches to avoid bugs or security issues. >> >>>> For major versions, the fact that a new major is released should not be >>>> the defining factor, we cannot expect everyone to be able to immediately >>>> jump on a new version. In a dependency ridden world there is never a >>>> guarantee developers can even update. >> >> I have mentioned the idea of supporting the current release and one >> previous major, like the node project, in the past but it seems most people >> are in favor of only supporting the current major. >> Most do not want to back-port changes to a previous release. >> >> I was saying to deprecate past major when a new major is released only >> based on the information that most were in favor of only supporting the >> current. >> >> Anyways, I am OK if we support the current major and one past version. >> >> For Example: >> Cordova 9 >> Cordova 10 >> >> But I think we should not be supporting & should officially deprecate the >> packages for >> Cordova CLI 0.0.1 >> Cordova CLI 1.x >> Cordova CLI 2.x >> … >> Cordova CLI 8.x >> >> And so on for the other packages, we also have. >> >> >>> On Aug 19, 2020, at 10:30, Chris Brody <chris.br...@gmail.com> wrote: >>> >>> For minor version bumps I had meant not deprecating the previous minor >>> version but only supporting 1-2 minor versions back. But my recollection >> is >>> that we generally have not published so many minor version updates >> between >>> the most recent major versions, so this may be pretty meaningless. >>> >>> I would agree that this is a bit aggressive. I had even proposed an idea >> of >>> extended LTS support in the past: >>> https://github.com/apache/cordova-discuss/issues/39 >>> >>> Over the past couple of years I have seen issues pile up and take longer >>> than desired to be resolved. Here is a very unfortunate example: >>> https://github.com/apache/cordova-ios/issues/764 >>> >>> My impression is that almost all maintainers are overworked volunteers, >> and >>> that new features and even sometimes breaking changes are needed to keep >> up >>> with the ever-changing platform landscape. >>> >>> >>> On Tue, Aug 18, 2020 at 12:47 PM Jesse <purplecabb...@gmail.com> wrote: >>> >>>> I think this stance is too aggressive. >>>> >>>> For minor version bumps there is no need to deprecate the previous minor >>>> as any support request should be met with ‘update’ >>>> >>>> For major versions, the fact that a new major is released should not be >>>> the defining factor, we cannot expect everyone to be able to immediately >>>> jump on a new version. In a dependency ridden world there is never a >>>> guarantee developers can even update. >>>> >>>> I think we should look at other major projects ( node itself even ) for >>>> inspiration. >>>> Ignore odd/even majors, I suggest reading thru >>>> https://nodejs.org/en/about/releases/ >>>> >>>> >>>> >>>>> On Aug 18, 2020, at 6:31 AM, Chris Brody <chris.br...@gmail.com> >> wrote: >>>>> >>>>> >>>>>> >>>>>> * When releasing a patch, deprecate the last patch release within the >>>> same subset. >>>>> >>>>> +1 >>>>> >>>>>> * When releasing a minor, nothing happens. >>>>> >>>>> I would favor a slightly more flexible approach on this: >>>>> >>>>> - only support 1-2 minor versions back >>>>> - It goes without saying that if a security release needs a minor >>>>> release, which seems to have happened on Node.js, then previous >>>>> minor(s) should be deprecated. >>>>> - If a critical update needs a minor release, consider deprecating >>>>> previous minor(s). >>>>> >>>>> Though we did not seem to have very many minor releases between the >>>>> recent major releases. >>>>> >>>>>> * When releasing a major, deprecate the entire previous major >>>> (including patches and minors). >>>>> >>>>> +1 >>>>> >>>>>> I will start a vote within 12-24 hours after keeping this discussion >>>> thread open for any feedback, modifications, or additions. >>>>> >>>>> +1 >>>>> >>>>> I wonder if there should be a draft PR on cordova-coho before stariing >>>> the vote? >>>>> >>>>>> I will be creating a separate discussion thread & vote for actually >>>> deprecating the existing out-dated npm package. >>>>>> [...] >>>>> >>>>> +1 >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org >>>>> For additional commands, e-mail: dev-h...@cordova.apache.org >>>>> >>>> >> >>
