It's 2022 and there's still no official way to deploy to the store through CICD

It might have been easier to just add a note in the description of the original app that it's no longer supported with a link to your version, published by you, with your developer key, manifest ID, etc.

When it comes to publishing, each time you do that it resets some stats in the store used to show popularity, etc.  It's not something you want to do for something really minor or every day, so bunch  a few of these together before uploading, and test on a real device with a sideload in the mean time.   If you are updating the store on a regular basis more than every month or so, you may want to review your own development process. You probably don't even need a login script as it shouldn't be that common.  Build an IQ, login using the website, and upload... That's what I do with the 50 or so apps I have in the store

Programming 101 - which I took in the mid 70's!

I know it could have been easier to do that but as the datafield was existing before I added new features, and was already used by a lot of people, I wanted to keep it streamlined. Also maybe one day I won't have time to develop it anymore and somebody else will take over. Application lifecycles, especially open source applications, should not be dependent on a single person handling the release. At the very least, there should be a way to share a CIQ application page between multiple accounts.

People should not have to reinstall a datafield, reset their data pages and change all the settings because of developers going AWOL. I totally understand that the current way works, and it can suit some people, but that should not be the only option available in 2022. Era of the waterfall development with biannual releases is long gone, I would like to be able to bring new features or bugfixes quickly, without worrying about trivial things like app store publication.

Releases don't need to be biannual.  But they should be done after testing and not just if any change is made.  Each time you update the store, you lose all ERAs from the previous version. so if you update today, you could have had 10 app crashes yesterday you won't see.  Critical bug fixes are one thing.  Simple bug fixes or changes, different.  Controlled updates to the store and not just all the time.

When did I say that I would release without any testing ? What I want to do is being able to create a release (and that is independent from new code change) and push it to the store without manual intervention. Anyway, I don't even understand why you are arguing with me about this, it's not like it would change anything for you if Garmin added the possibility, it would just make another option available.

It's a 2 step process to manually update the store so a minor thing.  Why should Garmin change? Doing a script is overkill to me.  How often are you updating the store?  Sounds like more than needed to me, and you lose things like stats and ERAs when you do. 

As far as a second login to the store, have you tried just using two browsers - one on your real account and one with the original developer?

I can't see Garmin changing this, as you noted, this was discussed years ago.

I dont have a solution but Garmin should allow for ownership and co maintainer changes so you can transfers ownership and co-maint to people.

To automatic releases are nice to have but IMO we need to be able to setup a CI first without the threat of Garmin taking away your ability to develop apps because of the EULA. 

he's arguing with everyone

I saw an open source project that had an upload script included (not sure any more in which script language it was written and I also didn't test if it actually worked), (I guess it might have been your repo that I saw samuel?)

It would be great if there was an official garmin api which allowed to update store contents, but this is not a small task to implement such an api.... 

Transfer of ownership should probably not be hard to implement, all you need is a page to transfer the app to someone else, the other author to accept it and as a result to update a record in the database I guess. I wonder how often this would need to happen though (probably not often...), a first step to see this implemented is to do a feature request in the bug report forum so that it at least is on the dev team radar.  

I also would like to see unit test implementation improvements (and filed a few reports for it) but as there are not a lot of users that actually implement unit tests I've accepted it's unlikely to be something that's high priority on their backlog...

peterdedecker said:

Transfer of ownership should probably not be hard to implement, all you need is a page to transfer the app to someone else, the other author to accept it and as a result to update a record in the database I guess.

Not to state the obvious but you'd also need to be able to change the private key associated with an app. Seems like this might be a little clumsy unless there was a requirement that you upload a newly built version of the app (signed with new key) at the same time that you request transfer of ownership. Alternatively, there would have to be some sort of token you can sign with the private key and submit with the ownership transfer request.

FlowState what happens when you revoke your old key and start using a new key? Or you lost it and republish an app with the new key? How is that solved? Same problem in regards to key management.