Definition of Done

If it works for the team, and gives them confidence in the quality of the Done increment, then it's hard to say it could be a bad idea. 



I would suggest two things though based on patterns i've seen; 



If there is so much to do that creating a DoD is hard, this probably deserved it's own retro. How do we simplify, automate, or throw away processes that aren't actually helping us?  This thing with multiple versions, as well as documentation, sound like prime candidates to inspect and adapt. 



secondly, don't try to solve with a DoD what can just be solved with technical practice. 



Ie, if you can make something a requirement against the PR, then it probably doesn't need to be called out in the DoD. Simply meeting the requirements for the PR will ensure quality. 



Remember that the value of the DoD is not as an artifact, it's in the quality that results. That's the thing we're optimizing for. Ensure your DoD captures the things needed to create the desired quality that might otherwise be missed. You don't need to state the obvious, and you don't need to write down things that will happen anyway. 

At the moment we are creating DoD for our team 

There's your problem, right there. A Definition of Done is for the product. It's a guarantee of usable quality for each product Increment. It isn't per team.

If you have multiple products and product versions, the value of each of which needs optimizing and accounting for, then each would need a DoD to assure an increment's quality. Transparency is needed over these separate value streams, their quality, their prioritization, and the focus your team is losing by taking them all on.

I wrote an article that may help:

https://www.agileconnection.com/article/using-definition-done-promote-continuous-improvement

One thing I advocate is that you don't look at the different things you do as different types.  Everything is a Product Backlog Item.  Treat them all equally. 

Second thing I advocate goes along with @Ian's response.  The Definition of Done is not about the different items you do or the team.  It is about the Product.  It is a written agreement by the Scrum Team that will indicate the quality and state of the Product iteration when the team states it is "Done".  It should be easily understood by parties outside of the Scrum Team because the intent is for them to better understand what you mean by "Done".  

There can be an organizational level Definition of Done and then each team can create their own to add further guidance for the product that they support not the items that they complete.