Re: [Health] Incompatible version of server (demo account)

[Axel Braun]

Am 25. Dezember 2014 23:04:42 GMT+13:00, schrieb "Cédric Krier" <address@hidden>:
>On 25 Dec 20:05, Axel Braun wrote:
>> Am Montag, 22. Dezember 2014, 22:28:52 schrieb Cédric Krier:
>> 
>> > > This kind of problems proofs that the client should be
>> > > backwards-compatible. although the Tryton maintainer has a
>different view
>> > > on this...
>> > It is not a proof at all! The client behaves correctly by showing a
>> > correct error message.
>> > Backward compatibility is an aberration.
>> 
>> Right, the client works as designed.
>> And the design is right according to academic principles, or
>according to 
>> 'true religion'.
>> 
>> But there is a real world, and the troubles that esp. new users have,
>proof 
>> that the design is an aberration. You need to think big, Ced!
>
>The current design is thinking big, backward compatibility is thinking
>small.

This is a statement, not an argument.
Tryton focus is still to much on development, and too less on end users. So it is small, as it misses the holistic picture. 

>> There are certain advantages that backward compatibility has
>> - fix bugs only in one location/version, instead of all versions
>> - use the latest client and take advantage from all bugfixes applied
>so far.
>
>Both statements show a lack of knowledge in software design and
>maintenance.

Thin ice, mate!
You should not judge something where you have basic info missing (about my background)

>It is not because something is backward compatible that it means you
>don't have the bug fixes older versions.

You would just maintain one version, not n (where n is the number of active Tryton releases)

>> - and maybe the largest one, esp in once you run Tryton in a larger 
>> organization: have one client and be able to test / try various 
>> Tryton/GNUHealth versions. 
>
>Being able to install different version of Tryton is a limitation of
>Python packaging system. But it is doable because we do it for Windows
>and I'm pretty sure it is doable by packager:
>https://mail.python.org/pipermail/python-dev/2010-August/103128.html

Sure every package maintainer can work around this. But this would increase overall workload, and will make sure every distribution does it different. 
Better to solve this at source. 
So if you do it for Windows, why not in general?


>> Useful e.g. for testing release upgrades. I know, someone (Nicolas?)
>proposed 
>> to tweak/script some way around it, but this is not user friendly.
>
>I don't understand. This has nothing to do with client backward
>compatibility.

This comes back to the focus on end users.

>> I agree that a backward compatibility to ancient releases is not a
>good 
>> way...see A20 gate!
>
>You are mixing topics. We are not talking about hardware nor OS.

Ok, here is another example: you may know that MS changes the file format of the office documents slightly in each release. Just imagine you can.open a Word 2003 Document just with MSO 2003, not with 2007, 2010 or 2013.

That does not only sound like a nightmare, it is actually one!

>> Successful companies and projects have one thing in common: They
>listen to 
>> the needs of their customers / users. 
>
>You are just hearing what you want to hear and try to force us to do
>some work for you. This doesn't work this way.

Not at all. I can work around this if necessary, but an average user can not. That was the starting point of this thread (which we better continue on tryton-dev).
And, think back to TUL2014, there were more discussion in that direction. Tryton needs to focus more on end user/ decision taker, and not only on developer.

>> Maybe we make a poll for this?
>
>Don't care of a poll if nobody does the work.
>If you care so much about writing a backward compatible client, feel
>free to do it. It is free-software.

Sure, this is one potential way to do it. But for the moment I'll enjoy the rest of my vacation. 
Schöne Grüße 
Axel
-- 
Written from cell phone. Excuses for typos.