Backwards compatability

[WhiteFire-Sondergaard]

Can we have a long term stable version, or should I just ignore nPose 3 and fork myself my own nPose 2? Removing core functionality (DEFAULT for example) is not something I want to deal with running my store.

I went through this with Wendy's Open Collar where the API changed constantly, not interested in doing it again.

[HowardBaxton]

V2.01 is a very stable release and is still available for use ehich does not require all the modifications to upgrade.  Many users stay with V2.01.  It is still offered at nPose HQ inworld and on Github.Upgrading to V3.10 is possibly something to consider for new builds or if any of the new features would be useful. In defense of the upgrades, they were needed to allow nPose to grow.  The features that V3.10 offer could not happen without making these changes.  V3.10 has been released for over 2 years and is also a very stable version.Pick what works for you.Howard -------- Original message --------From: WhiteFire <[email protected]> Date: 6/18/19 4:31 PM (GMT-08:00) To: nPoseTeam/nPose-V3 <[email protected]> Cc: Subscribed <[email protected]> Subject: [nPoseTeam/nPose-V3] Backwards compatability (#31) Can we have a long term stable version, or should I just ignore nPose 3 and fork myself my own nPose 2? Removing core functionality (DEFAULT for example) is not something I want to deal with running my store. I went through this with Wendy's Open Collar where the API changed constantly, not interested in doing it again. —You are receiving this because you are subscribed to this thread.Reply to this email directly, view it on GitHub, or mute the thread. [ { "@context": "http://schema.org", "@type": "EmailMessage", "potentialAction": { "@type": "ViewAction", "target": "#31?email_source=notifications\u0026email_token=AA3SNIWK77HNU75HMXBTQJTP3FV6PA5CNFSM4HZEUTSKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4G2ISB7Q", "url": "#31?email_source=notifications\u0026email_token=AA3SNIWK77HNU75HMXBTQJTP3FV6PA5CNFSM4HZEUTSKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4G2ISB7Q", "name": "View Issue" }, "description": "View this Issue on GitHub", "publisher": { "@type": "Organization", "name": "GitHub", "url": "https://github.com" } } ]

[LeonaMorro]

Hi,
I'm the one who is responsible for the changes in V3 ...
I'm also a fan of backward compatibility, but there are a few things when I would vote against it:

1. if fixing a bug is not possible otherwise
2. if I see a design descission that leads to overcomplicated workarounds inside the code (we only have 64K!)
3. if I see a design descission that forces the user to make workarounds
4. if I see timing or multiuser issues inside the code (problems that may happen but are mostly invisible and may or may not be reproducable). Because they are often not reproducable they must be eliminated on sight.
5. if I really want to add a major feature or a bunch of features and it is not possible to add it otherwise (and (thanks to Howard) I try hard to keep its backward compatibility)

I hope that are good reasons ...

My point of view:
V2.01: is ok. It has some multiuser and timing issues inside the main scripts but I guess you could use it with several persons for a year without triggering one of them, nevertheless they are there. If you have a working nPose V2.01 object I see no compelling reason to update it.

V3.10: will be likely the the last version in the V3 era and I don't know of any major issues. If you start a new project I would be using this. API changes because of 1+2+3+4+5 in the above list

V4: The next release (hopefully this year) will be V4 and it implements some new features. There will also some (very?) minor "API" changes (considerably less as between V2 and V3). API changes because of 2+3+5 in the above list.

Removing core functionality (DEFAULT for example) ...

Well it isn't removed it just changed ... (I currently don't know of anythig that can be made in V2 but not in V3)
Defining the default card:
V2: instead of naming the the card as usual SET:xyz you have to name it DEFAULT:xyz
V3: add the following line to your .init NC (if you don't have one, create one): DEFAULTCARD|SET:xyz

PS: If I speak of bad design descission ... I don't want to say that anyone did a bad job ... I mean we all (this includes me) are making descissions and some of them are good and some of them are not as good and we are not able to see a bad descission in the moment we make the descission but we see them later.