Mercurial: Class library that will exist for both .NET 3.5 and 4.0?

I have a rather big class library written in .NET 3.5 that I'd like to upgrade to make available for .NET 4.0 as well.

In that process, I will rip out a lot of old junk, and rewrite some code to better take advantage of the new classes and support in .NET 4.0 (like TPL.) The class libraries will thus diverge, but still be similar enough that some bug-fixes can be done to both in the same manner.

How should I best organize this class library in Mercurial? I'm using Kiln (fogbugz) if that matters.

I'm thinking:开发者_如何学Go

1. Named branches in one repository, can then transplant any bugfixes from one to the other
2. Unnamed branches in one repository, can also transplant, but I think this will look messy
3. Separate repositories, will have to reimplement the bugfixes (or use a non-mercurial-integraded compare tool to help me)

What would you do? (any other alternatives that I haven't though of is welcome as well.)

Note that the class libraries will diverge pretty heavily in areas, I have some remnants of old collection-type code that does something similar to Linq that I will remove, and some code that uses it that I will rewrite to use the Linq-methods instead. As such, just copying the project files and using #if NET40..#endif sections is not going to work out. Also, the 3.5 version of the class library will not be getting many new features, mostly just critical bug-fixes, so keeping both versions equally "alive" isn't really necessary. Thus, separate copies of all the files are good enough.

---

Edit From @Rudi's answer here, I think what he's saying is this:

1. Create two branches (or keep one "default" and create another branch for the other path, which would be "default"=.NET 4.0, and "net35"=.NET 3.5 in my case)
2. Develop them along their diverging paths
3. When a critical bugfix is found, and this exists in both versions (ie. in both 3.5 and 4.0), and can be fixed in common code, since the 3.5 version won't accrue a lot of new functionality, it means the bug was most likely present in the original version (before I branched)
4. I thus create another branch, off of the original version (or very close to it), implement my bugfix, and then I merge this tip into both the 3.5 and the 4.0 branches to update them both.

I will have to think about this. It seems merging in Mercurial pulls in the files, not the changes, which means any changes done to the files that needs to be bugfixed, risks being "merged" back to an earlier stage, but I'll have to test it.

---

I would use two clones for the different environments (=basically two anonymous branches), maybe also with different branch names within each clone. Also I would use a new branch for each bug fix or interchangeable feature, starting as nearest to the branch point as possible, to make merges between the main branches easier. I would try to develop the bug fixes in the 3.5 branch, since it is more likely that bug fixes in the 4.0 tree would cause merge problems due to other changes there (I'm not saying that this approach does not cause any problems).