But we only have the run-time environment in PROD, so it is not possible to override the application ID during deployment.Have you seen this?
Using generate_offset during import works great, but has a disadvantage that each developer's export, after an export split, contains new ID's, making each version totally different from the version under version control.Same problem here in a slightly different scenario!
Luis Cabral wrote:The only way seems to be import the application from PROD into the same application number in DEV, but this has an impact in the development process as no new development can be done until the bug is fixed.Do you want to do a new development on the version without fix the bug ? How is it possible (the bug will be there or no ?) ?
jozef_SVK wrote:I have explained the problem in my original post but I am happy to explain it again (hopefully in a more clear way this time) because I find this very important.
I normal use two env's DEV and PROD as you.
There are the applications with the same ID's on both env's (there is no problem with any dance of ID's).
Do you want to do a new development on the version without fix the bug ? How is it possible (the bug will be there or no ?) ?Obviously the bug will be fixed in the DEV version as well as part of the new development, but as explained above the fix cannot wait for the current work there to finish to be deployed to PROD.
jozef_SVK wrote:If this is done, all the internal IDs (not only the application ID itself) of the DEV version will change, which defeats the purpose of doing this.
1) You could try to export actual DEV version of the application for example 100.
2) Import it back into DEV env but with different ID (e.g. 101) - development can continues on app 101.
4) Export 101 from DEV and import it back to DEV as 100When it is imported back into app number 100 they will change once again! Internal IDs change every time you import an app under a different ID. Not very helpful from a CVS perspective.