[jbosstools-dev] Release Process

[Rob Stryker]

I'm inclined to believe we should just get rid of our ejb3 
implementation. It serves no purpose now and keeping it around can only 
confuse users.

It's purpose was to provide an ejb3-light facet, which could then be 
combined with the dynamic web facet to make a seam project.

We already have a seam project. And a seam facet. Neither of which uses 
the ejb3 facet from what I can tell. Therefore the jboss ejb3 project, 
and its facet, has become useless.

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.
>
> 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? =)
>
> 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.
>>>
>>
>
>