Issues of moving from Version of cspro to another

Other discussions about CSPro
Post Reply
Posts: 4
Joined: December 3rd, 2017, 4:57 am

Issues of moving from Version of cspro to another

Post by harerimana2000 » March 31st, 2021, 3:46 am

Dear USCensus bureau cspro specialists,
I have a suggestion about developing different cspro versions.Since cspro was used as data entry capture for several years and has known development milestones,we ahd so many versions.For the first days we developed cspro apps in windows , but as technology grows,we moved from windows to endroid technology.It is surely good to continue developing defferent versions of cspro.But we as users of cspro we face sometimes challenges such as moving from version to another among others.For example now, if you have app developed in cspro 7.2 and you wish to migrate to 7.5 you are required to change a lot of things especially paths and soome other logics need to be changed.I 'd suggest from you, while moving from one version,the features of previous version should be kept in new one and add others features as it is always done.What I want to say is , If I have my app in cspro 7.2 and I decide to move to 7.5 and other later versions which are coming soon, I should not have any problem while running my app. New vesrions can have new capabilities for sure.



Gregory Martin
Posts: 1534
Joined: December 5th, 2011, 11:27 pm
Location: Washington, DC

Re: Issues of moving from Version of cspro to another

Post by Gregory Martin » March 31st, 2021, 5:10 am

We try to maintain the ability for CSPro to be backwards compatible. The first version number of CSPro changes when there are really large changes (like 4.1 -> 5.0, where Unicode support was added, which changed the way that files were written; or 6.3 -> 7.0, which introduced the CSPro DB file format), but a minor version change like 7.2 -> 7.5 should not introduce such changes.

Some things, however, are out of our control. You mention that paths changed. We did have to change the location of the csentry folder on Android, but that was forced upon us due to security changes made by Google to the Android operation system. If you use hardcoded paths in your logic, you would have a problem upgrading, but if used the pathname function and used relative paths instead, there would be no problem.

What other logic did you have to change? Perhaps we can suggest an alternative way of writing some logic. We test the backwards compatibility with applications that we write, but it is possible that we made a mistake and broke some old functionality.

Post Reply