[ https://issues.jboss.org/browse/JBIDE-22355?page=com.atlassian.jira.plugi... ] Nick Boldt commented on JBIDE-22355: ------------------------------------ If we're adding new features/plugins to support something upstream, eg., OpenShift v3.2 or EAP 7.1, those features could be Alpha while the rest of the openshift project is Final. Once those features are ready for release, they could be merged from topic branch into master, and then they'd be considered safe enough to be included, built, and supported. Thus, if code is in master, it's supported. If it's not ready to be supported, it shouldn't be in master. See also https://www.infoq.com/presentations/Facebook-Release-Process That way whatever we decide to call it, with or without a BUILD_ALIAS, as prefix or suffix, I can simply pull the latest CI, built from master Thursday night, and turn that into a staged build on Friday for QE to test. That build can then be released to /development/ or /stable/ on the following Mon, and demoed on Tues. I don't understand what you mean by "examples on a timeline". If you feel my example (a - g) above was exactly the same as we do things now, that's because regardless of whether we use BUILD_ALIAS or not, that's how things work for resolving remote vs. local. -- This message was sent by Atlassian JIRA (v6.4.11#64026)