You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Bryan Ellis <er...@apache.org> on 2020/08/18 07:24:13 UTC
[DISCUSS] NPM Package Deprecation
I have not seen any documentation or guidelines on npm package management concerning deprecations.
Within the last, so many releases that I have performed, I have not once deprecated a package.
From our previous stances on version support, we typically only support the current major release.
In this discussion, I want to define a process to ensure we properly deprecate our older packages.
When we release a patch, minor, or major, we should deprecate accordingly.
Using our previous stance in version support, I believe we should follow guidelines as such:
* When releasing a patch, deprecate the last patch release within the same subset.
* When releasing a minor, nothing happens.
* When releasing a major, deprecate the entire previous major (including patches and minors).
E.g. Follows in liner time:
1.0.0 release
1.1.0 release
1.2.0 release
1.2.1 release & 1.2.0 deprecated
1.2.2 release & 1.2.1 deprecated
2.0.0 release & 1.1.0 deprecated, 1.2.2 deprecated
I will start a vote within 12-24 hours after keeping this discussion thread open for any feedback, modifications, or additions.
Additional notes to be prepared on:
I will be creating a separate discussion thread & vote for actually deprecating the existing out-dated npm package.
Most of or all of our existing out-dated packages are not deprecated.
For example, Cordova CLI from version `0.0.1` -> `9.0.0` are still active.
This separate discussion thread will include nightlies & also auto deprecation for nightlies.
Expect this in another thread to be coming.
Re: [DISCUSS] NPM Package Deprecation
Posted by Bryan Ellis <er...@apache.org>.
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 <pu...@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 <ch...@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 <pu...@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 <ch...@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-unsubscribe@cordova.apache.org
>>>>> For additional commands, e-mail: dev-help@cordova.apache.org
>>>>>
>>>>
>>
>>
Re: [DISCUSS] NPM Package Deprecation
Posted by Jesse <pu...@gmail.com>.
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 <ch...@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 <pu...@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 <ch...@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-unsubscribe@cordova.apache.org
> >>> For additional commands, e-mail: dev-help@cordova.apache.org
> >>>
> >>
>
>
Re: [DISCUSS] NPM Package Deprecation
Posted by Bryan Ellis <er...@apache.org>.
>> 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 <ch...@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 <pu...@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 <ch...@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-unsubscribe@cordova.apache.org
>>> For additional commands, e-mail: dev-help@cordova.apache.org
>>>
>>
Re: [DISCUSS] NPM Package Deprecation
Posted by Chris Brody <ch...@gmail.com>.
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 <pu...@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 <ch...@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-unsubscribe@cordova.apache.org
> > For additional commands, e-mail: dev-help@cordova.apache.org
> >
>
Re: [DISCUSS] NPM Package Deprecation
Posted by Jesse <pu...@gmail.com>.
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 <ch...@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-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
Re: [DISCUSS] NPM Package Deprecation
Posted by Chris Brody <ch...@gmail.com>.
> * 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-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org