Personally i would rather see items from the 2022 roadmap completed before pushing them back to the back of the queue again to make way for the next idea.
Things like the backup manager. As i always tell people, losing a site is not a huge issue, you can republish, losing data is a business ending catastrophe.
And of course many long awaited app connect features.
Database migrations for a specific target are done automatically when you use the “publish” button to publish your project to specific target.
The database manager indeed has some specific views of data and schema for the current target, but we might add there also a dropdown for the target just as with the file manager, or show all targets in the database manager tree ( still under discussion of the best way)
We really need a "dump to .sql file" facility in Database Manager.
You can add a feature request for this.
I assumed that was what you meant on the 2022 roadmap
Now THAT would be a useful feature! 
Are you saying your development instance is connected to your production database?
If so, this might work for you, but it is not the standard practice in most businesses and has a high chance of causing production outages.
Yes, I build mainly internal dashboards for the company I work for. In order to build it I need data. Sometimes thousands of records. I find with proper backing up it works great. I have never had a problem in 20+ years I have been doing it for them.
I think there is way more chance of overwriting live data with development data which would be much worse in my opinion.
I know it's not the most common practice. But it's the only way I can develop my dashboards. Saves time on having to create/edit tables twice etc as well.
Don't get me wrong, I think the FR is a good one. But I think it can causemore problems rather than fix a problem that doesn't exsist.
If this is the solution to the annoying issue of the global database connection changing randomly when using the database resource manager, then I'm all for it.
My main concern is that I use the server connect global options as a way to manage my SEO (as outlined in one of @Hyperbytes videos), would that be affected?
If using environment variables, would there be an option to have multiples? For example, if I am understanding this correctly, the global section of the Workflows would be moved into this new area? I have multiple Mailer's set up (depending on what I am emailing out). I think I have the same with the S3 Storage option.
Nope, the Execute steps of Globals are not per target, so they would not be impacted by this.
Everything else (DB connections, JWT Signing, Mailer, Oauth2, S3 Storage and Security Providers and ENV vars) have target specific settings and can only be changed by choosing an Active target. I believe ALL of that would/should move into the new Target Manager.
If that's the case, then I do not see it as an issue. But my use of Wappler is not as advanced as most of you so I might not be seeing the same concerns.
You do you, Brad!
But you are not describing anything unique...we all have data (some of us millions of rows) and replicating a db schema and/or data is something every db manager can manage for you without inserting risk (in fact, it reduces it). It's just another thing to be learned.
So while I'm all for people having various workflows, the tool should not be based on what is widely considered bad practice.
Odd, I haven't set up many projects and very rarely set up a new one but I don't remember ever having to switch targets to set mailer, Security Providers and DB connections. I have never used or even know what JWT Signing, Oauth2, S3 Storage so I can't comment on those.
Again, the request may be very valid. I just personally don't see what problem it solves. This is a great discussion, I may learn something 
ENV would seem to be the easy choice as it is standardized, but maybe the low-code manner is to add them as ENV behind the scenes, rather than directly calling them that in the UI. I don't have a strong opinion on this one.
I totally agree, but it shouldn't 'force' you to host, use and maintain two databases either. In my opinion this change would require more work not less having to maintain two databases. And would require users to use the database manager. Which has it's own issues and downfalls/risks.
New components will be copied to other targets so you would only notice if you need different values for different targets or made edits later.
I can't image it would...that is not mentioned here at all, right?
Again, it's likely just me not understanding the issue or what is being proposed. That's just old age me. I'm not against the request. As long as it doesn't break my projects I have set up and force me to change my workflow of 25 years.
Again, just a me thing I don't find the Database manager user friendly or trustworthy. And, I may be wrong, but this change would require a user to use it?
I'm just paranoid.
I do not use the Wappler db manager either, and while I'm not building the Target Manager, I again can't imagine a reason to require the use of the db manager.
