[ https://issues.jboss.org/browse/JBDS-3208?page=com.atlassian.jira.plugin.... ] Nick Boldt commented on JBDS-3208: ---------------------------------- Mickael said: {quote} I'm just not sure about why requirement should be there [under the mars folder], as several of them are really used in multiple steams simultaneously.{quote} The Denis *agreed* but said the opposite as far as stream categorization goes: {quote}I'd rather put them right under mars folder{quote}. So... while it's true that some reqs span multiple releases, these are the minority, not the majority. I still think they make sense located under their own "stream", and by separating them into snapshot/development/stable, we can in theory do future cleanup more easily. As to moving reqs around, that seems unlikely, but may be necessary when we move from target platform CRx to Final. Thus... * when we pull some new CI build of Tern, we put it in */snapshots/* * when we pull Mars M5, we put it in */development/* * when we pull Mars RC4/R, we put it in */stable/* * when we rename a CRx target platform to Final, we ensure that the .target files contain no /snapshots/ or /development/ entries, only /stable/. This can easily be written as some kind of string grep test, or even some xslt. To solve the issue of a requirement used for more than one stream... we can use symlinks between mars/stable/updates/<some req>/<version> and neptune/stable/updates/<some req>/<version> so that the req is available _as if it's one for Neptune_, until a newer version arrives. (In many cases we have been known to simply DROP requirements because they don't work with the latest Eclipse, then re-add them months later when a newer version DOES appear which DOES work.) Max, are you suggesting we do /mars/updates/requirements/\{{color:red}snapshots{color},{color:orange}staging{color},{color:blue}development{color},{color:green}stable{color}\}/ instead of /mars/\{{color:red}snapshots{color},{color:orange}staging{color},{color:blue}development{color},{color:green}stable{color}\}/updates/requirements/ ? We can do that but then we would have a *different hierarchy* for requirements vs. for targetplatforms, builds, update sites, etc. -- This message was sent by Atlassian JIRA (v6.3.8#6338)