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 >
