[ https://issues.jboss.org/browse/JBIDE-11512?page=com.atlassian.jira.plugi... ] Nick Boldt commented on JBIDE-11512: ------------------------------------ we already have 40+ stable_branch jobs. All that's needed to bump them from Beta1 SVN branch to Beta3 branch is to: 1. pull down the latest versions from Jenkins (using 'hudpull' script), 2. do a global find and replace on the config.xml files, s#Beta1#Beta3#g s#<disabled>true</disabled>#<disabled>false</disabled>#g 3. push changes to the server (using 'hudpush' script) 4. commit changed config.xml files to SVN For generating jobs from a template, (eg., the FIRST time we branch on a new stream, like when we start JBDS 6.0M1 and need to spawn 40 new jobs from trunk) there's this: https://github.com/nickboldt/maven-plugins/tree/master/hudson-job-publish... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-11512?page=com.atlassian.jira.plugi... ] Mickael Istria commented on JBIDE-11512: ---------------------------------------- The issue is that there can be huge differences between stable_branch and trunk. For example, we added tests in trunk and configured hudson jobs consequently. Hudson jobs maintenance is synchronized with code maintenance, and code maintenance is using branch. Maintaining an alternative approach such as the one we have currently is less clear and make daily maintenance more difficult and less clear (need to apply changes on branch all the time although modification is not part of previous branch roadmap/tasks). It seems like creating a new view by copying DevStudio_Trunk into DevStudio_3.3.Beta3 wouldn't be much more work than applying changes you suggested; and it would allow us to be synchronized with the code we build and prevent us from having to backport useless changes into "Stable_Branch". For any structural change happens between Stable_Branch and BetaN+1 (let's say a move to Git for example), then we need to do the work twice since we cannot backport this structural change. Whereas following the same "pattern" as for development using branches, we are sure we'll never encouter this issue. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-11512?page=com.atlassian.jira.plugi... ] Mickael Istria updated JBIDE-11512: ----------------------------------- Fix Version/s: 3.3.0.Beta3 (was: 3.3.0.CR1) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-11512?page=com.atlassian.jira.plugi... ] Nick Boldt commented on JBIDE-11512: ------------------------------------ Your above workflow is only needed when it's time to branch for the FIRST MILESTONE on a stream, eg., we'll need this for the JBT 3.4M1 / JBDS6.0M1 builds. Otherwise the existing stable_branch jobs can simply be edited and reused as you move from branch to branch through a stream, because let's be real, you'll NEVER have to rebuild something from, for example, the M5 branch using the current stable_branch job. We only move forward, not sideways. I agree however that when it's time for the first milestone, you DO need a new view, series of jobs cloned from trunk, updated cascade docs [1], and so forth. [1] http://download.jboss.org/jbosstools/builds/cascade/3.3.indigo.html I also agree that migrating the old version of a stable_branch job to is newer equivalent is a bit tedious. I'm just not convinced that creating new jobs and destroying old ones is the way to go, because changing job names every 6 weeks is a royal pain in the ass from a maintenance POV and means you have to ensure all your composite sites are properly config'd thereafter. If you can simply generate jobs based on trunk, why not generate them using the same names as existant, and push them to the server using my hudpull/hudpush pair? Related... I wrote a mojo [1] to do this based on a template, but if could be adjusted to work using regex replacements, eg., job foo_trunk -> foo_stable_branch and uses svn repo in trunk -> branches/3.3.0.some.milestone, etc. [1] https://github.com/nickboldt/maven-plugins/tree/master/hudson-job-publish... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-11512?page=com.atlassian.jira.plugi... ] Mickael Istria updated JBIDE-11512: ----------------------------------- Fix Version/s: 3.3.0.CR1 (was: 3.3.0.Beta3) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JBIDE-11512?page=com.atlassian.jira.plugi... ] Mickael Istria updated JBIDE-11512: ----------------------------------- Fix Version/s: 3.4.x (was: 3.3.0.CR1) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira