[jbosstools-dev] Release Process

[Max Rydahl Andersen]

Marshall Culpepper wrote:
> Sounds good to me.. does "rest of jbosstools" include seam tools? what 
> about freemarkerIDE? Also, Rob should tag EJB3 tools as well.

freemarker - max (i guesS)

> It would be easier to have one "big tag", but if there are any problems 
> with a specific component, wouldn't it be faster to only re-tag their 
> component instead of the whole repo? =)

makes sense...what do you suggest what names we should use in /branches 
  and /tags ?

/max

> 
> Max Rydahl Andersen wrote:
>> Hi Marshall,
>>
>> I guess it's time to hashout what we want to tag and who does it ;)
>>
>> If we follow the "normal ways" it's something like:
>>
>> jbpm - koen
>> hibernatetools - max
>> jbossas - rob
>> rest of jbosstools - denis/alexey (?)
>>
>> Did I forget something ?
>>
>> Alternatively we could simply do one branch/tag for everything but jbpm ?
>>
>> /max
>>
>>> Hey guys..
>>>
>>> I wanted to hash out the release process we're going to use for the 
>>> upcoming betas and GAs of JBossTools and RHDS.
>>>
>>> Below I've listed what I think should be our release process moving 
>>> forward. This is heavily based on the process we used for JBossIDE, 
>>> with some changes to accomodate our new QA resources.
>>>
>>> 1) All top level components (i.e. "jsf", "richfaces", 
>>> "hibernatetools", "as", etc) are given a tag. In the case of major 
>>> releases (GAs / major functionality changes), we branch instead of 
>>> tag. In the case of a branch, we use HEAD of that branch as the tag 
>>> (any changes needing to be made during the release process will be 
>>> just committed to HEAD in that branch rather than 
>>> re-tagging/re-branching)
>>> 2) An integration build is ran on those tags. If there are any errors 
>>> in the build, the offending components must fix any code/bugs and 
>>> re-tag.
>>> 3) All component owners do smoke testing of their respective code 
>>> (this is just a smoke test to ensure things are working properly).
>>> 4) If there are any problems in the smoke testing, the component 
>>> owner is responsible for making the change, re-tagging, and we will 
>>> re-run the integration build (coming back to step #2)
>>> 5) Once we have an integration build that everyone is happy with, we 
>>> will run the release build, and pass that on to QA for testing. Any 
>>> problems in this process go back to step #2 for fixing/re-tagging 
>>> (though at this point we continue with release builds instead of 
>>> integration builds)
>>> 6) When QA gives the thumbs up we can make the release. The build is 
>>> uploaded to our update site, which receives one last smoke test from 
>>> each component lead. (Any problems are fixed/re-tagged/re-tested).
>>> 7) Finally we upload the release to Sourceforge, our build server, 
>>> the public update site, and make the announcement on forums, blogs, 
>>> the download pages, etc.
>>>
>>
> 
>