>> 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 >>> >>
