Request for Version History

[Mesh]

Don, whenever the version history indicates changes and fixes to XYcopy, it always makes me nervous because I end up wondering if there are integrity issues with file transfer operations that have occurred in the past.

I don't know if people need a detailed history for XYcopy (although I certainly wouldn't complain), but I think it would be good to know whether any of the bug fixes were significant, as well as whether there is any concern for past file operations.

[nas8e9]

Don, whenever the version history indicates changes and fixes to XYcopy, it always makes me nervous because I end up wondering if there are integrity issues with file transfer operations that have occurred in the past.

I don't know if people need a detailed history for XYcopy (although I certainly wouldn't complain), but I think it would be good to know whether any of the bug fixes were significant, as well as whether there is any concern for past file operations.

To set the scene for others, could you post links to previously reported *integrity* issues with XYcopy? (I like to think I keep up with XYcopy and I don't recall such reports, hence my question.)

To be sure, those integrity issues you mention pertain only to XYcopy or also to before/besides XYcopy?

As for a changelog for XYcopy, I'm not sure: often I see non-specific mention of changes to XYcopy in combination with a XYcopy-related changelog item further up. I'm hoping that any fixes for potentially data-corrupting bugs are already flagged conspicuously.

[Mesh]

To set the scene for others, could you post links to previously reported *integrity* issues with XYcopy? (I like to think I keep up with XYcopy and I don't recall such reports, hence my question.)

I don't know whether that has occurred or not. All I'm saying is that when a file operation engine has bugs fixed, it's prudent to question whether those bugs may have caused integrity issues.

[admin]

When the change log has something like this...

Code: Select all

* XYcopy 2.00.0053: Internal changes and fixes.

... the reason is:
XYcopy shares code with XYplorer. If this shared code is changed (such changes are usually mentioned in the change log) then both XYplorer and XYcopy have to be recompiled and updated. Copy+pasting "Internal changes and fixes." in such cases just saves me time. The message is: "Don't forget to update XYcopy when you download this beta version."

[Mesh]

When the change log has something like this...

Code: Select all

* XYcopy 2.00.0053: Internal changes and fixes.

... the reason is:
XYcopy shares code with XYplorer. If this shared code is changed (such changes are usually mentioned in the change log) then both XYplorer and XYcopy have to be recompiled and updated. Copy+pasting "Internal changes and fixes." in such cases just saves me time. The message is: "Don't forget to update XYcopy when you download this beta version."

Ah! Thank you, then.

[tux.]

If they "share code", XYcopy is an integral part of XYplorer; so why is it branded and versioned separately at all?

[admin]

If they "share code", XYcopy is an integral part of XYplorer; so why is it branded and versioned separately at all?

Not all of XYcopy's code is shared.

[tux.]

But it is depending on it, right?

[admin]

But it is depending on it, right?

The source codes overlap that's all. What's the problem?

[tux.]

The missing transparency.

[admin]

The missing transparency.

Transparency is no good as such (even if the pirate party says so). And it does not apply here anyway. Both EXEs are different programs with partly overlapping source codes. No reason, let alone need, to share the version number. I would find it quite confusing actually.

[PeterH]

Shure it could be better, if both would have the same version.

But then XYcopy had to change it's version with XY, even if nothing changed within.

I think here is no right or wrong - Don just has to decide. But, as XYcopy is delivered/installed with *every* XY-install, it wouldn't be very strange if it changes version every time. (And I hope Don could automate thís change as well?)

[PeterH]

The missing transparency.

Transparency is no good as such (even if the pirate party says so). And it does not apply here anyway. Both EXEs are different programs with partly overlapping source codes. No reason, let alone need, to share the version number. I would find it quite confusing actually.

...but both are in some way related: you shouldn't use not-fitting versions with each other? And this would be easyer to see if both had the same version string.

[admin]

The missing transparency.

Transparency is no good as such (even if the pirate party says so). And it does not apply here anyway. Both EXEs are different programs with partly overlapping source codes. No reason, let alone need, to share the version number. I would find it quite confusing actually.

...but both are in some way related: you shouldn't use not-fitting versions with each other? And this would be easyer to see if both had the same version string.

XYplorer.exe takes care that the expected XYcopy.exe version is present. This is enough.

[tux.]

So how should the user know which version is "expected" if they are entirely independent applications?