Improvement suggestion: full changelogs

As someone recently struggling greatly to stay on top of multiple integrations with various bugs that appear in them, combined with silent breaking changes/compatibility issues within SDKBOX that occur, I have thought hard about what could be done to improve the maintaining of SDKBOX integrations.

Would it be possible to organise, and maintain full changelogs of all integrations as well as sdkbox versions? It seems like changelogs have gone silent since 2.2 (and we are currently above 2.4.x). Together with explanations for any and all Android manifest changes.

Sharing full changelogs not only tells us what is new but can warn us for potential changes that may break or be incompatible across upgrading.
In my experience, the integration of Analytics & Onesignal has turned my Android manifest into a unmaintainable wasteland with the sdkbox installer constantly re-adding entries and being warned in the changelog with full explanation whenever new permissions or service declarations are added would be greatly appreciated and allow me to manually check all changes are compatible / applied properly.

(As a separate topic here outside the scope of this thread, I think the automatic modification of the Manifest is utterly unmaintainable, the installer cannot understand the state of the current manifest and creates duplicate entries all the time whenever they are user edited. I think the manifest is not a machine generated or simple file and not suitable for an installer to be touching)

3 Likes

Thanks for your suggestions.

Changelogs of SDKBox is here:
http://docs.sdkbox.com/en/release-note/

what can I do for this? add a new argument for no modify manifest:

sdkbox import iap --no-manifest

?

it’s a bug, sdkbox should handle this.

I see regarding the release-notes, I totally couldn’t find this page while I was updating modules, it may be better to make sure this has links (especially next to download current version buttons/ version numbers) on the individual plugin pages? It’d make this clearer to find

what can I do for this? add a new argument for no modify manifest:

I feel like this should be the default as the manifest is a very customized file and dangerous to automatically modify, maybe with clearer process for instructing users to make manifest modifications (together with explanations for any changes)

The issues I mainly see are services being re-added (sure, I can report this some time as an individual bug next time I update) as well instances of __ Application_Id __ and the likes that need to be replaced by the user, and are re-added since it seems the scripts don’t detect their modified versions

(automatic updating and adding of __ Application_Id __ is also very ugly since the installer has no way to warn the user to replace these placeholders across versions, so updating ends up as a build-and-guess trial and error to fix the manifest each time)

Thanks for your suggestion.

I got you, and we have --nopatching argument for not patch files:

--nopatching          skip all patching commands when executing package script.

Example:

sdkbox update --nopatching
# or
sdkbox import admob --nopatching