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