Hi, an extraction of the existing V3 code into an own branch (or repo) is IMHO a good decision.
With the separation between the V3 and V4 specific code the actual V3 (Client) and V4 (Client/Server) architecture and code can be simplified and will be better understandable for developers and users of the library (as base for a client or server implementation). I agree with the point that there might be more maintenance because of two branches but I also think that with a cleaner architecture and reduced LOC within each branch there will be less bugs and issues which then results in less maintenance. At the end the effort for fixes will be the same but each branch (V3/V4) for itself is better understandable and maintainable. And I think that there are more use cases and developers which just need to consume either a V3 or a V4 service and not both versions within an single client so that library focus should be on a clear and clean separation of both versions. Over all I think we should create separate code lines for both versions. In a first step as branches (e.g. "V3.x" and "master" for V4) and in a future step in separate git repositories (like actual with "V2" and "V3/V4"). Kind regards, Michael > On 06 Feb 2015, at 17:42, Ted Jones <[email protected]> wrote: > > Great point about the shared/common code Francesco. The way I have handled > that in git with other projects is to create a separate git repo for the > common code and import that into my workspace when developing in the other > repos, v3 and v4 in this case. > > Another, less attractive option IMO, is to treat the common code as a > submodule. > > I don't think duplicating the shared code is a viable option though. >
smime.p7s
Description: S/MIME cryptographic signature
