[jbosstools-issues] [JBoss JIRA] (JBIDE-13671) Replace build timestamp in qualifier by last-mod-timestamp from git

[ https://issues.jboss.org/browse/JBIDE-13671?page=com.atlassian.jira.plugi... ] Max Rydahl Andersen commented on JBIDE-13671: --------------------------------------------- {quote} "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? {quote} If you use a different TP that affects the feature.xml resolution of what the 0.0.0 refers to does it not ? Thus it will behave differently since the content is actually different. {quote} "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. {quote} It is a valid option in JBossrojectVersoining assuming you don't release two under same name. {quote} 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. {quote} Yes, this part of getting incremental updates is a *good* thing, but can't we get there withuot having duplicate copies of the same things ? If they really are so much teh same as you want them to be, why don't we delete the new duplicates ? {quote} "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. {quote} I'm not sure what your point is - how are you going to support not having a maintanence branch and product branch for developer studio ? I know how it is done for locus - simply by us not changing things and have multiple versions in there. But that can't be applied for something as bing as developer studio afaics. {quote} 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 {quote} Yes, this is what I want too - but with the above you are no longer sure you get the same bits when testing/installing/updated. If you installed early you get the old build of freemarker, if you installed month later you get the new one, but if you update you stay on the old build. -- This message was sent by Atlassian JIRA (v6.4.11#64026)