Need help with mercurial branching structure

We have just switched from SVN to HG and discussing on branching structures. We have came up with the following structure, need some reviews and want to know if this structure cause problems in the future.

                  * Tag v1.2.0
                  |
                  * Merge Branch v1.2.0 into Default 
                 /|
                / | 
               *  |
               |\ |
Merge v1.1.2   | \| 
 fixes into    |  * Tag v1.1.2
 v1.2.0 branch |  |
               |  * Merge Branch v1.1.2 into Default
               |  |\
               |  |  \
   Commit code *  |   * Commit a bug fix
               |  |   |
               |  |   |
Merge v1.1.1   *  |   * Branch v1.1.2
 fixes into    |\ |  /
 v1.2.0 branch | \| /
               |  * Tag v1.1.1
               |  |
               |  * Merge Branch v1.1.1 into Default
   Commit code *  |\
               |  |  * Commit a bug fix
               |  |  |
 Branch v1.2.0 *  |  * Branch v1.1.1
                \ | /
                 \|/
                  * Tag v1.1.0

• Each tagging represents a version release.
• Bug fixes happen only on v0.0.x branches
• Minor improvements and minor new features (cosmetic upda开发者_开发问答tes to the UI, etc.) happen only on v0.x.x branches
• The default branch (center) has always stable and tested code

Questions:

• After merging v1.2.0 into default branch, will we able to create a branch for v1.1.3 from tag v1.1.2 and relase/tag v1.1.3?
• Does this structure a valid structure or are we trying to come up something absurd and there is already a solution/answer to this?

---

UPDATE: After discussing the solution provided by Lasse V. Karlsen, we have finally agreed that we won't need to release v1.1.3 after releasing v1.2.0. Our users should update to v1.2.0 line if they want to receive updates and v1.1.2 will be the last update for v1.1.x line. So, this way the first question is eliminated. Thanks for the great advise and tip Lasse.

Thank you all!

---

You would not be able to retroactively introduce 1.1.3 as a changeset along the default timeline, the best you can hope for is as follows:

1. Update back to default at the point where you released 1.1.2
2. Branch out for 1.1.3 and commit
3. Merge this with the 1.1.2 tag in default, this will create another head on default branch, parallel to the 1.2 timeline you're now working on
4. Tag for 1.1.3 and release
5. Merge this new head into previous head, getting the bugfix into 1.2.x

Caveat: One thing that I discovered when I tested this is that .hgtags had to be merged when I merged the 1.1.3 default content into the 1.2.0 default content. Since tags are always read from the tipmost changeset (I could be wrong here), this might indicate that this is not the best way to do this. At the very least I would perhaps wait with the tagging until I had merged 1.1.3 into the 1.2.0 timeline (ie. topmost merge in diagram below.)

My test repository can be found here: https://lassevk.kilnhg.com/Repo/StackOverflow/answers/SO6071322

It would look something like this:

                  * Merge Branch 1.1.3 into Default
                  |\
                  | \
                  |  * Tag v1.1.3
                  |  |
                  |  * Merge Branch v1.1.3 into 1.1.x Default 
                  |  |\
                  |  | \
Tag v1.2.0        *  |  * Commit a bug fix
                  |  |  |
                  |  |  |
Merge Branch      *  |  * Branch v1.1.3
v1.2.0 into      /|  | /
Default         / |  |/
               *  |  +
               |\ | /
Merge v1.1.2   | \|/ 
 fixes into    |  * Tag v1.1.2
 v1.2.0 branch |  |
               |  * Merge Branch v1.1.2 into Default
               :  :

Whether or not this is a good idea, not sure, I've yet to manage a project with lots of parallel releases like this in Mercurial.