Got it. Thanks Daniel for leading this On Tue, Mar 31, 2020 at 7:40 PM Daniel Imberman <daniel.imber...@gmail.com> wrote:
> I think including both is fine as long as the old one contains deprecation > warnings/force a feature flag to allow it (e.g. —allow-deprecated) > > via Newton Mail > <https://cloudmagic.com/k/d/mailapp?ct=dx&cv=10.0.32&pv=10.14.6&source=email_footer_2> > > On Tue, Mar 31, 2020 at 11:33 AM, Kamil Breguła <kamil.breg...@polidea.com> > wrote: > > On Sun, Mar 22, 2020 at 9:20 AM Robin Edwards <r...@bidnamic.com> wrote: > > > Also does the new API need to be feature complete or just enough > > functionality to warrant removing the existing experimental one. > > > > I think we should release at least one version that will contain the > new and old REST APIs simultaneously. It is not easy to upgrade two > complex systems at the same time. However, if we do this, some users > will have to do it. Older versions can be hidden behind the feature > gate. We can also add deprecation warnings. > > > > > R > > > > On Fri, 20 Mar 2020, 20:29 Daniel Imberman, <daniel.imber...@gmail.com> > > wrote: > > > > > Great! Hope to get a few more folx to give +1's but I think we have a > good > > > path forward here :) > > > > > > On Fri, Mar 20, 2020 at 12:51 PM Jarek Potiuk < > jarek.pot...@polidea.com> > > > wrote: > > > > > > > > > > > > > > > > > > I agree especially for larger-scale users migrations are a > difficult > > > > > process. Perhaps we can adopt something similar to a blockchain > fork > > > > (e.g. > > > > > determine X known airflow using companies, and start the countdown > as > > > > soon > > > > > as Y% of them migrate). I really just want to make sure we don't > end up > > > > > with a python2/3 situation. Even if we continue support it should > only > > > be > > > > > for bugfixes and we should not add any new features into 1.10. > > > > > > > > > > > > > I think we are in perfect sync - I think feature-migration should end > > > > almost immediately after we release 2.0. But bug-fixing should > continue > > > > for quite some time. On that front - having backport packages will > help > > > > with releasing "integrations" quite independently from 1.10/2.0 > version > > > > (which I think is good for those who are - for this or another > reason - > > > > stuck on 2.0). On the other hand we should make sure that the > important > > > > stuff for 2.0 that is not "feature" is also backported to 1.10. For > > > example > > > > a lot of recent performance improvements that we have now in 2.0 will > > > > be possible (and not that complex) to backport to 1.10. Some of this > > > effort > > > > is actually easier to do in 2.0 and then apply to 1.10 in similar > fashion > > > > as it is easier to understand and reason about the 2.0 code now when > > > > we have some refactoring/pylints etc in place. So we should make sure > > > > we get the latest 1.10 to a "good" state - before we freeze it for > bugfix > > > > only. > > > > I know it might mean that some people will stay with 1.10 for > longer, but > > > > that's also OK for them. The reason to migrate to 2.0 should be not > > > > performance but some important features (like API or HA) that come > > > > with it. > > > > > > > > I couldn't agree more :). If we can start people writing (close to) > 2.0 > > > > > compliant DAGs before the release of 2.0 that will make the > migration > > > > > process so much easier :). > > > > > > > > > > > > > Yeah. I even thought that we should write a > > > > "How good your DAGs are for 2.0" assessment tool. > > > > > > > > > > > > > If there aren't any extra steps or features that we need to add > (beyond > > > > the > > > > > ones discussed here), I think a good next step would be to create > an > > > > > official checklist just so we can see all of these features in one > > > place > > > > > (and hopefully start breaking them down into as small of changes as > > > > > possible). > > > > > > > > > > Does that sound ok? > > > > > > > > > > > > > Perfectly OK for me! > > > > > > > > > > > > > > > > > > -- > > > > > > > > Jarek Potiuk > > > > Polidea <https://www.polidea.com/> | Principal Software Engineer > > > > > > > > M: +48 660 796 129 <+48660796129> > > > > [image: Polidea] <https://www.polidea.com/> > > > > > > > > >
