[ https://issues.jboss.org/browse/JBDS-3191?page=com.atlassian.jira.plugin.... ] Mickael Istria commented on JBDS-3191: -------------------------------------- {quote}Please note that the first line item in the release guide for JBDS 8 milestones...{quote} Ok, but in that case, I only followed the "staging" document. And this step you mention is more about preparing the build for a .GA candidate. This should be mentioned earlier, at least at the beginning of the Staging documentation. {quote}Having the stable site in there from day 1 (I assume you mean the day Beta1 is pushed to https://www.jboss.org/products/devstudio ) will mean that everyone using the Betas won't be able to see updates, and won't be able to automatically move up to CR or GA.{quote} The idea isn't to populate the final URL from day 1, but reference it systematically, even if it is empty. {quote}I think it's better to define maven enforcer rules which run at build-time to cause the build to fail if parent pom version is Final and the above files still contain development milestone (not release/stable) URLs. {quote} Compared to the startup extension looking at version of com.jboss.devstudio.core feature to decide how to populate the available sites? If yes, what are the benfit/inconvenients of one approach on the other. What I see as a benefit of having it at runtime using regular Eclipse code is that anyone could contribute patches to this piece of code. Also, if we drop Maven one day, it would still work. It's even testable from the IDE. Another benefit is that if this is well implemented, we'll never need to change again. Whereas even if we have an enforcer rule but still rely on properties in pom files, we'll have to make a commit to change stuff in pom or to tweak a CI job. -- This message was sent by Atlassian JIRA (v6.3.1#6329)