Page 2 of 2
Re: Request for Version History
Posted: 26 Sep 2011 14:09
by admin
tux. wrote:So how should the user know which version is "expected" if they are entirely independent applications?
XYplorer tells the user if the file is wrong. XYplorer is not dependent on XYcopy. It runs well without. XYcopy is only needed for backgrounding file operations.
Re: Request for Version History
Posted: 26 Sep 2011 15:33
by PeterH
OK: if VB would allow "native" multi-threading an external program as XYcopy wouldn't exist - it's function would be integrated into XY. (This is what I normally would expect.) And so it wouldn't / couldn't have other version than "the base" program.
Now, for VB, it's split off, and has different version info - though it's somehow related to the XY-version.
Thinking this way I come to the conclusion that it could be expected and helpful if both versions were the same.
Though I won't die if it's not the case...
Re: Request for Version History
Posted: 26 Sep 2011 15:43
by admin
PeterH wrote:Though I won't die if it's not the case...
Good to know.
A version change is related to source code changes and recompilation. Everything else would be cheating. And would force users to update their XYcopy.exe very often although it is hardly ever necessary. Not my intention.
Re: Request for Version History
Posted: 27 Sep 2011 00:16
by PeterH
admin wrote:PeterH wrote:Though I won't die if it's not the case...
Good to know.
A version change is related to source code changes and recompilation. Everything else would be cheating. And would force users to update their XYcopy.exe very often although it is hardly ever necessary. Not my intention.
I don't understand...
I update XYcopy when I update XY.
When should I not update XYcopy, if updating XY? Could you give us a table?
No: nonsense. For me they belong together like twins.
But it seems internally you do this work: you define in XY which version of XYcopy is required, and must change that when XYcopy-version changes. Wouldn't it be easier and more logical to always await the same version of XYcopy as XY has (and knows)? Like twins, as I said before...
Don't get me wrong: I don't mind, I always handle both as a pair. (OK: it's not me, it's your installation routine
) I just don't understand your reasons.
(Still alive
)
Re: Request for Version History
Posted: 27 Sep 2011 01:39
by j_c_hallgren
PeterH wrote:I update XYcopy when I update XY.
When should I not update XYcopy, if updating XY? Could you give us a table?
No: nonsense. For me they belong together like twins.
But it seems internally you do this work: you define in XY which version of XYcopy is required, and must change that when XYcopy-version changes. Wouldn't it be easier and more logical to always await the same version of XYcopy as XY has (and knows)? Like twins, as I said before...
I suspect it's less like twins and more like a parent/child so that just because parent gets a new vers, doesn't require a new child...given that a majority of XY features do not require XYcopy so why would you want to tie them together?
Another analogy is a browser and a specialized plug-in...fixes to browser not related to that plug-in would never require a new plug-in just to keep vers nbrs the same...and even plug-in fixes may occur w/o a browser vers chg...all very typical situations so I don't see your problem.
Re: Request for Version History
Posted: 27 Sep 2011 12:30
by admin
j_c_hallgren wrote:Another analogy is a browser and a specialized plug-in...fixes to browser not related to that plug-in would never require a new plug-in just to keep vers nbrs the same...and even plug-in fixes may occur w/o a browser vers chg...all very typical situations so I don't see your problem.
Absolutely! Well put.
Re: Request for Version History
Posted: 27 Sep 2011 15:53
by PeterH
admin wrote:j_c_hallgren wrote:Another analogy is a browser and a specialized plug-in...fixes to browser not related to that plug-in would never require a new plug-in just to keep vers nbrs the same...and even plug-in fixes may occur w/o a browser vers chg...all very typical situations so I don't see your problem.
Absolutely! Well put.
You think of a plug-in never changed for itself, but only changed together with the browser?
And that's only distributed with the browser - but with every distribution of the browser?
I don't know such a thing.
But if there would be one: I would like it to have the version of the browser.
So I continue not to understand what you think...
...but sometimes hope you begin to understand what I think
Re: Request for Version History
Posted: 27 Sep 2011 16:07
by admin
Sorry guys, but I leave this thread now. No problem, no solution, no understanding. Buffled why you spend your life time on this...
Re: Request for Version History
Posted: 27 Sep 2011 17:33
by j_c_hallgren
PeterH wrote:You think of a plug-in never changed for itself, but only changed together with the browser?
And that's only distributed with the browser - but with every distribution of the browser?
I don't know such a thing.
But if there would be one: I would like it to have the version of the browser.
So I continue not to understand what you think...
...but sometimes hope you begin to understand what I think
Let me try again -- here's a recent Beta update to XY itself:
Code: Select all
v10.20.0012 - 2011-09-14 12:10
+ Configuration | General: Added option "Mixed sort on path
columns". Check to use a mixed sort (mix folders and files when
sorting) always on the columns Path (Search Results) and Original
Location (Recycle Bin).
+ Toolbar | Delete: The button now has a context menu.
* Updated the help file.
Do you see ANYTHING in there that should cause XYcopy to have its vers nbr bumped to match? I can't!
XY and XYcopy are two
separate modules and move at different speeds in terms of vers nbrs...I could show you dozens of other appl that have similar situations and where vers nbrs vary widely between modules that make up that package...and look at Windows itself! There are likely thousands of various vers nbrs on a given setup.
I'd ask you to check some of your other appl's that have multiple EXE or DLL and see if ALL their EXE/DLL share common vers nbrs...I'd highly suspect that many will not.
I just can't understand what your issue is...when one or both of XY modeles get updated, you apply those updates from one common source...as long as Don puts vers that work together in a release, its doesn't matter one whit what vers nbrs they are and if they are in sync or not.
Re: Request for Version History
Posted: 28 Sep 2011 23:15
by PeterH
OK: one more post - to answer to J_Cs post...
We are looking from different point of views.
You see XYcopy on it's own, and await that different versions of it mean different code.
I see the distribution-package with XY + XYcopy as belonging together, and would like to give this combi a version, belonging to both programs.
I don't think it's comparable to windows with it's modules. As, for examples with patches, windows modules can be replaced, while windows keeps it's version. But I never saw a version change of XYcopy without new XY.
As far as I understand XY checks the correct version of XYcopy. If windows would do the same it wouldn't be able to work with a patched module - windows itself would have to be changed to know the expected new version of that module. (Think of changing a displaydriver, arising the need to change the windows version...)
That is: the relation of "windows-version" and the version of it's modules is much more loose as that of XY and XYcopy. Or the other way round: the versions of XY and XYcopy are much more related as those in windows - what could be shown in taking the same version for both.
From my point of view it isn't interesting if XYcopy Vx and Vy are identical or different - it's only the question if they "fit" to the current XY. This could easy be verified, if both are the same version - else I or you, but at least XY must have explicite info, which versions correlate.
I think I stop it here - but still am convinced that using the same version for both would have advantages.