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