Plan for WinMerge 2.16

[christianlist]

It looks like WinMerge 3 is taking a lot longer than expected, so I think it makes sense to keep WinMerge 2.x alive for a while longer. At least until we get more traction on WinMerge 3.

Let's set a goal for WinMerge 2.16, so we know when it's done.
I think the goal should be to this: Release a 64 bit version of WinMerge.

I've been running a local version of WinMerge in 64 bit for almost a year now.
It runs just fine in 64 bit, but we are missing two things.

1. The plugins are not converted to 64 bit.
2. We don't have a 64 bit installer.

For the plugins I know some will say, just drop them and be done with it.
But I think our plugins is one of the features that make WinMerge stand out as a more useful tool than other compare and merge tools.

We have some plugins in C++ and some in VB6.
The C++ plugins should be fairly simple to compile in x64.
The VB6 plugins will have to be rewritten or dropped.

I suggest we drop the current VB6 plugins, unless someone volunteers to rewrite them.
Instead I suggest we try to adopt the approach that the xDofDiff Plugin has taken (see http://freemind.s57.xrea.com/xdocdiffPlugin/en/index.html for info on xDocDiff Plugin).
xDocDiff has long been the most popular 3rd party plugin for WinMerge.
It is unfortunately also build in VB6.
xDocDiff is built using xdoc2txt (see http://www31.ocn.ne.jp/~h_ishida/xdoc2txt.html for details, and for those who don't speak Japanese Google translate is your savior http://translate.google.com/translate?hl=en&sl=ja&tl=en&u=http%3A%2F%2Fwww31.ocn.ne.jp%2F~h_ishida%2Fxdoc2txt.html)
In version 2.0 of xdoc2txt there is a C++ example which could easily be extended into a WinMerge plugin.
To distribute xdoc2txt with WinMerge, we would need to contact the author and get his permission.
We would also need to contact the author to see if he can provide a 64 bit version of xdoc2txt. Without a 64 bit version, it's pointless to even try this.
If anyone would like to take on this project or have a better idea, then please let me know?

For the installer, I see several options.
1. Improve the InnoSetup installer to distribute 64 bit.
2. Improve the WiX installer to:
2a. Deliver a 32 and a 64 bit installer as separate msi files (Windows Installer does not support both in the same msi).
2b. Create a WiX bootstrapper to deliver both 32 and 64 bit in a single executable.
2c. Drop support for 32 bit and deliver only a 64 bit msi file.

I'd really like to improve the WiX installer to where it can replace the InnoSetup installer.
I think I will even take on this project myself.
Option 2c is the easiest, but dropping 32 bit support is somewhat controversial. What do you all think?
Alternatively, 2b is the easiest to figure out for our users. There will only be one executable installer to download and run, but creating a WiX bootstrapper is a non-trivial piece of work. But WiX bootstrappers are using WPF, so maybe there is a WPF programmer out there who'd like to take on this part?
We may end up starting with 2a and then we'll see what happens after that.

[gerundt]

I personaly think we should drop the "Rudimentary Visual SourceSafe and Rational ClearCase integration". We have no active developer who supported and tested it. It should reduce source code and translation strings.

I also think we should simplify the 7-Zip support. Could we not deliver all componets with the normal setup and ignore a standaline installation from 7-Zip? It is really confusing and complex thing for normal users.

It looks like WinMerge 3 is taking a lot longer than expected, so I think it makes sense to keep WinMerge 2.x alive for a while longer.

Sounds good!

We may end up starting with 2a and then we'll see what happens after that.

The current WIX-Script should create separate msi files for 32 and 64 bit:

• msbuild.exe WinMerge.wixproj /p:Platform=x86
• msbuild.exe WinMerge.wixproj /p:Platform=x64

[kimmov]

It looks like WinMerge 3 is taking a lot longer than expected, so I think it makes sense to keep WinMerge 2.x alive for a while longer. At least until we get more traction on WinMerge 3.

I've been trying to get WinMerge 3 going many times but every time it gets into silence after few messages. I really don't know what is going on... Even if it got now started to be very active it would be long time before anything usable would be available. But then I think there really is no resources for two projects...

I think we have discussed earlier if we could start radically modifying WinMerge 2.x instead of starting from scratch. In the way we keep having something usable all the time even though we are practically rewriting the thing. If the rewrite hasn't taken off yet maybe we should try the another way. Maybe it would be more attractive for people wanting to contribute?

That doesn't remove the need for big decisions about toolkits, diff engines etc. But maybe we can then make those decisions as we go on improving things rather than first making all the decisions and only after that start coding. If there is interest, please start new topic for that...

For the plugins I know some will say, just drop them and be done with it.
But I think our plugins is one of the features that make WinMerge stand out as a more useful tool than other compare and merge tools.

Yes, that one includes me. Plugin problems and all the bugs caused them are listed in many topics, tracker etc. But it is also true they fill in real user's needs. And I'm not saying there could not be plugins. Just that the current implementation must go at some point. You don't want to execute unknown code in your computer but plugins do just that...

Option 2c is the easiest, but dropping 32 bit support is somewhat controversial. What do you all think?

Dropping 32-bit support is not really possible in next 10 years. Even though lots of users already run 64-bit Windows there will be old machines for years where one wants to run WinMerge.

[kimmov]

I personaly think we should drop the "Rudimentary Visual SourceSafe and Rational ClearCase integration". We have no active developer who supported and tested it. It should reduce source code and translation strings.

Agreed.

I also think we should simplify the 7-Zip support. Could we not deliver all componets with the normal setup and ignore a standaline installation from 7-Zip? It is really confusing and complex thing for normal users.

The problem is that we have no any control over 7-zip releases. The idea with separate setup was one can update just 7-zip support when new 7-zip version is released. We don't need to do new WinMerge release just for that. Waiting six months or one year for support for latest 7-zip is a bit long time.

[christianlist]

I personaly think we should drop the "Rudimentary Visual SourceSafe and Rational ClearCase integration". We have no active developer who supported and tested it. It should reduce source code and translation strings.

Agreed.

I agree to.

[christianlist]

I also think we should simplify the 7-Zip support. Could we not deliver all componets with the normal setup and ignore a standaline installation from 7-Zip? It is really confusing and complex thing for normal users.

The problem is that we have no any control over 7-zip releases. The idea with separate setup was one can update just 7-zip support when new 7-zip version is released. We don't need to do new WinMerge release just for that. Waiting six months or one year for support for latest 7-zip is a bit long time.

Including 7-zip support in the installer itself may not be the best idea, but making it simpler to install would definitely be good.
Right now it has a low download count compared to WinMerge itself, and I think it's mainly because it's just too difficult to install.

Maybe some system were the installer looks for the latest version we have published and downloads it on-demand.
Or maybe a build in "check for updates" feature in WinMerge which would download and install it when requested.

[kimmov]

Right now it has a low download count compared to WinMerge itself, and I think it's mainly because it's just too difficult to install.

I don't believe it is too difficult. It may be a bit hard to discover though. But I'm not sure how to make it easier to discover other than the current menuitem?

Maybe some system were the installer looks for the latest version we have published and downloads it on-demand.
Or maybe a build in "check for updates" feature in WinMerge which would download and install it when requested.

Lots of on-line installers do this so it would be familiar for users too. Problem is we can't assume every machine has internet connection. So you still need to allow offline installing too and not bother user with "cannot connect" errors etc.

[gerundt]

Btw, what will the base for R2_16? Use we Trunk one day or create the Branch with R2_14 as base?

For dropping CC and VSS support I create first patches for Trunk:

PATCH #3025 Drop ClearCase and Visual SourceSafe support
https://sourceforge.net/p/winmerge/patches/3025/

[kimmov]

Btw, what will the base for R2_16? Use we Trunk one day or create the Branch with R2_14 as base?

That really depends what we want to do?

If we just want to keep updating translations and some minor fixes, then the R2_14 base would be good and safe choise.

If we want real development then I guess the trunk status is better for that. I haven't really looked what has happened in trun, but I guess not much. And quickly looking Sf.net repo browser I just don't know how to check trunk status. It seems Sf.net manages to consistently break everything that even worked earlier.

For the real development I'd move to Mercurial repository at Bitbucket anyway, like I suggested at developers-mailing list.

[christianlist]

Btw, what will the base for R2_16? Use we Trunk one day or create the Branch with R2_14 as base?

Let's use Trunk for now, and then some day when we get close to the release, we'll branch R2_16 from Trunk.

For R2_14 I'm not sure yet if we need a bug fix release.
There is a few bugs popping up, but I'm a little in doubt if they are serious enough to varant any more releases fro the R2_14 branch.