This portal is to open public enhancement requests against IBM Cloud and its products. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (https://ideas.ibm.com).
Shape the future of IBM!
We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:
Search existing ideas
Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updateson them if they matter to you. If you can't find what you are looking for,
Post your ideas
Post an idea.
Get feedback from the IBM team and other customers to refine your idea.
Follow the idea through the IBM Ideas process.
Specific links you will want to bookmark for future use
Application versioning is a really handful system for controlling an application deployment.
Zero-downtime deployment is now a must-have for every cloud-based application. It's not available by default and it's quite a shame (i think).
While the active-deploy service does quite the job, this still should be a in-app versioning logic (like in Google AppEngine or other clouds).
It could be implemented with the following logic:
1) Every application is deployed with a version number (if not specified, it could be for instance a git commit hash or a bluemix-generated version number)
2) We can stop and start application instances with a version number as a parameter (optional)
3) When pushing an application, the push logic will automatically replace the existing running application version with the new one with a ramp-up start/stop logic
4) Rollback will be available for an application with a version number as a parameter (optional. Bluemix should keep the last 4/5 versions deployed available).
I guess this would require core changes in cloudfoundry, but still this is important, because it's a better match to the DevOps deployment logic.
Do not place IBM confidential, company confidential, or personal information into any field.