[ https://issues.jboss.org/browse/JBIDE-13671?page=com.atlassian.jira.plugi... ] Nick Boldt commented on JBIDE-13671: ------------------------------------ "generating identical filenames for different content" Just because the upstream has changed doesn't mean the downstream is actually different. Sure, it might be built with something different upstream, but if it compiles and all the tests pass, isn't it effectively the same bits? If not, other than the addition of a buildID or newer timestamp, how would you KNOW it's different? Would it really BEHAVE differently? "How do we know which binary users actually have when their name is the same ?" Of course there's the buildinfo.json to tell you which versions of upstream were used for a given build or aggregate, but that won't flow through to the end user. The only way the end user will know which version of the otherwise identical build is by the BUILD_ALIAS, which will, once a milestone, force everything to be "new" again, even if the timestamp and commit SHA is the same. (This is what we did for JBDS 9.1 -- bump the parent pom, bump the ALIAS, and force users to install EVERYTHING all over again even when the bits were basically identical for may projects' plugins.) OTOH, if we trash the BUILD_ALIAS and just use timestamps (which is a valid option in https://developer.jboss.org/wiki/JBossProjectVersioning ) then there's no way for a user to know if the bits they have installed are the Alpha, Beta, CR, or Final/GA ones. All they can know is from which SHA in github came the source for the plugin/feature. But then they can do INCREMENTAL upgrades. Each version of JBT or DS is smaller compared to the previous one. So it's a win in that updating ever 3 or 6 weeks (after every 1 or 2 sprints drop a new release) will be much faster and more user friendly. "Also Locus does not have branches" If we're moving to a model of Being More Agile, then perhaps we don't need to use branches at all - just as Locus does. We would of course still tag after a release is done, based on the SHAs used to produce that release (as we did for JBDS 9.x). The only time branches need be used is for feature work that's not ready to be included in the master stream. Then project leads can cherry-pick those topic branches back into master when they're ready to be included. I'd also like to move to a model of "release every week" (even if that's only to /staging/, not /development/). In that workflow, having incremental updates for users is all the more important. And for QE too, so it's easier to see which plugins have actually changed week over week. Related: http://www.infoq.com/presentations/Facebook-Release-Process -- This message was sent by Atlassian JIRA (v6.4.11#64026)