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