Hi Tobias. Well, adding to the API wouldn't be a significant change there. What
would be significant is retaining previous versions in the remote repository. I
doubt we can get people to offer every version of their texts. Updates are
usually bug fixes and if they are not simply this, we usually break out the
module with a new name, e.g. the NASB1995 is a new module name to preserve the
95 edition, since the latest NASB module has translation differences now as it
is updated to the 2020 revision. If a user wants the previous edition, they can
grab the NASB1995.
If a user wants a previous SWORD version of a module, then we've done something
wrong.
Do you have a particular use case you have found which would benefit from
allowing previous SWORD versions to be installed?
On September 27, 2022 9:37:03 PM GMT+02:00, Tobias Klein <cont...@tklein.info>
wrote:
>Hi Troy,
>
>As I am thinking about module upgrade support for Ezra Bible App (currently
>not implemented) I am also (once more) asking myself why there isn't an API
>for installing arbitrary module versions with InstallMgr.
>
>The two additional use cases that I would like to have in the SWORD engine are:
>
>- Add a function to list the module versions for a given module and a given
>repository
>- Add a version parameter to the installModule function
>
>Would it be much effort to implement this in SWORD?
>
>Are there any existing design constraints that make it hard to add this?
>
>Best regards,
>Tobias
>
>_______________________________________________
>sword-devel mailing list: sword-devel@crosswire.org
>http://crosswire.org/mailman/listinfo/sword-devel
>Instructions to unsubscribe/change your settings at above page
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
_______________________________________________
sword-devel mailing list: sword-devel@crosswire.org
http://crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
