# WikiData

PageData:
==Table of Contents
[[TOC]]
== Creating a new Wiki page
>'''Method 1'''. Writing a Wiki''''''Word automatically creates a link to an editable the page.
 * Edit a page (by Edit button or by double clicking a page)
 * Simply type any WikiWord ( which is a joined capitalized word like-> ThisIsWikiWord ) in the page and click Save. 
 * The WikiWord becomes a hyperlink to create a new page.
 Examples:  ThisIsWikiPage,  MyVacation,  MyAlbumIn2005
This method is currently disabled. Wiki Links must be specific.

>'''Method 2'''. Use  [''''''[  and  ]''''''] to enclose just about any  page topic
 Examples:  [''''''[The Old Wise Man of Fantasia]'''''']
            [''''''[2006-02-15 Birth of my cousin]'''''']
>'''Method 3'''. Use  [''''''=  and  ]  works similar to method 2
 Examples:  [''''''=The Old Wise Man of Fantasia]
            [''''''=2006-02-15 Birth of my cousin]

== Basic Formatting   

'''Paragraphs''' [1]
 * '''Avoid indenting''' paragraphs.
 * '''Use blank lines''' to separate paragraphs.
 * You can use {'''br'''} to insert line break within a paragraph.   {red}'''NEW'''!{/red}

'''Monospace'''
	* Starting a line with space makes the whole line monospaced.
 This is an example of a monospaced line.

'''Lists'''
 * This is unnumbered list using '''space-asterisk''' 
 * You can also use '''tab-space'''. (If you can't type a TAB, use 8 spaces).  Or better yet just use  1 space.

Numbered List example:

 :* This is numbered list using '''tab-colon-asterisk'''.
 :* You can start a line with <space>:*<space>  
 :* or <space>:*<space> or <space>1.<space>  for lists.


'''Horizontal Line'''
	* Four dashes at the left margin: ''''''--''''''--

'''Comments'''
 * Lines starting with '''//''' are removed from the output

'''Emphasis'''
	* Use doubled single-quotes ('') for emphasis (usually italics)
	* Use tripled single-quotes (''') for strong emphasis (usually bold)
	* Use five single-quotes ('''''), or triples within doubles, for some other emphasis 
	* Use Six single-quotes, or triples within triples, to Break''''''Up Long''''''Bumpy''''''Words so that they do not become Wiki Name''''''s.
	* You can also use them to separate suffixes (like 's') from Wiki Name''''''s.  
	* Emphasis can be used multiple times within a line, but cannot cross line boundaries.
	* Use "-''_''" and "''_''-" for  -_underlining_-.

'''References'''
	* JoinCapitalizedWords to make local references. If the page is NOT YET created the link will LookLikeThis.
	* You can also use '''double brackets''' to create wiki words, for example, the format would be  '''[['''Wiki Word''']]''' [3]
	* Precede URLs with "http:" to create links automatically as in: http://www.c2.com/ 
	* Other kinds of links are mailto:my@email.com, ftp://www.ftp.com, news://ggroup.com
	* ISBN and Amazon(c) book link, use ISBN'':''0672320681 for example ISBN:0672320681

'''Imbedded Images'''
 * Imbedded images preceding url with '''img:''' like this:
  img''':'''http''':'''//c2.com/sig/wiki.gif  or image''':'''http''':'''//c2.com/sig/wiki.gif
img:http://c2.com/sig/wiki.gif 

'''Referencing files relative to the document root. (Local reference shortcut) {red}NEW!!12/2005{/red}'''
 * Note: '''local''': is not followed by slash characters.  For example, writing...
 1. link local file examples  
 
   writing... {blue}local'''''':wiki.css{/blue}      results to this link ->  local:wiki.css
   writing... {blue}local'''''':icon.png{/blue}      results to this link-->  local:icon.png
   If file is sub folder , simply write like this --> {blue}local'''''':images\icons\icon.png{/blue} 

 2. local image extensions

   The keyword $''''''image$ results in a reference to local'''''':images/page_Current''''''Page''''''Name. This allows each page to have a directory of local images.
   The keyword $''''''Page$ results in the name of the current page

 3. local image examples    
 
   writing... {blue}image'''''':local:icon.png{/blue} results to this --> image:local:icon.png  
   writing... {blue}imageleft'''''':local:icon.png and  imageright'''''':local:icon.png{/blue} work as follows...
imageleft:local:icon.png  
imageright:local:icon.png

{br}
'''Footnotes'''
	* You can use numeric and square bracket for a footnote. [2]
	* At the bottom, just add square bracket at first character of a line and the number.

== Other Types of Formatting
	* Three blank lines creates 1 blank line
	* '==','===','====' at the start of line creates Topic
	* Coloring text for {red}red{/red}, {green}green{/green}, {blue}blue{/blue} and {black}black{/black} are allowed but must be kept at minimum.  Remember wiki is not about fancy presentation but more about quality content.
	* Use ">" to indent a paragraph (first level).   You can  also use ">>" for second level. ">>>" for third level indentation or block quote. ''' Formerly, the pipe character '|' was used for this purpose.'''  Pipe character is now used for tables. see below.
	* Use also '''{'''italic'''}''' or '''{'''bold'''}''' to {italic}highlight longer texts or paragraphs.{/italic}
	* Precede url with image with  '''Imageleft:''' or '''Imageright:'''  or '''Imagecenter:'''to justify image.

== Alternate Labels to Links and Wiki Words
 * Use alternate label to hide URL or hyperlink  like this...
 #@91;Go to Cnn News|http''''''://cnn.com#@93;
yields this...   [Go to Cnn News|http://cnn.com] !!!
 * Use alternate label to hide WikiWord like this:  
 #@91;Go to my Wiki homepage=wikiasp#@93;
yields this...
[Go to my Wiki homepage=Wikiasp] !!!

== InterWiki Links
Examples:
 #@91;My Website=ElreySite::Vacation''''''Page#@93;   -> ''Goes to the page VacationPage of database ElreySite using My Website as link alias.''
 #@91;My Website=Elrey''''''Site::#@93;               -> ''Goes to default start page of database ElreySite using My Website as link alias.'' 
 #@91;Elrey''''''Site::Vacation''''''Page#@93;              -> ''Goes to the page VacationPage of database ElreySite using no link alias.''
 #@91;Elrey''''''Site::#@93;                          -> ''Goes to default start page of database ElreySite using no link alias.''

== Table of Contents
Each page may contain a Table of Contents. It will be calculated based on the Top Level Tops that start with a space that are found at the beginning of a line. ie ''''''== Name 

The table will be inserted in the output to replace a line that starts with [''''''[TOC]''''''].

== Clickable Images
 * Use same technique above to create clickable (note the space aroung the img link)
 #@91; img'''''':http''''''://c2.com/sig/wiki.gif |http''''''://c2.com#@93;
yields this...
[ img:http://c2.com/sig/wiki.gif |http://c2.com]

== Tables
 * {red}'''NEW'''!{/red} - Use '||' character to construct tables.  Each row can have a color scheme by using '|!', '!|', or '!!'. Each row need not end with '||'. For example

|| This is || Ordinary Row || a New WikiAsp Feature
!| This color scheme || Sample || One
|! This color scheme || Sample || Two
!! This color scheme || Sample || Three
|| Great feature 

|! S|| M|| T|| W|| T|| F|| S
||  ||  || 1|| 2|| 3|| 4|| 5
|| 6|| 7|| 8|| 9||10||11||12
||13||14||15||16||17||18||19
||20||21||22||23||24||25||26
||27||28||29||30||31||  || 

== Sample HTML ({red}'''NEW'''!{/red})

If you know HTML, you can also enter it and tailor your wiki pages to your heart's desire.

>This is useful for imbedding Source Code and programs.  [Search Google for the utility|http://www.google.com/search?q=CopySourceAsHTML]


   22     <microsoft.web>

   23         <converters>

   24             <add type="Microsoft.Web.Script.Serialization.Converters.DataSetConverter"/>

   25             <add type="Microsoft.Web.Script.Serialization.Converters.DataRowConverter"/>

   26             <add type="Microsoft.Web.Script.Serialization.Converters.DataTableConverter"/>

   27         </converters>

   28     </microsoft.web>

   29     <appSettings/>





>CopySourceAsHTML is a utility that preserves syntax coloring



    9 using System.Web.UI.WebControls.WebParts;

   10 using System.Web.UI.HtmlControls;

   11 

   12 public partial class AddData : System.Web.UI.Page {

   13 

   14     protected void Button1_Click(object sender, EventArgs e) {

   15 

   16         int numItemsToAdd = Int32.Parse(NumAdd.Text);

   17         string categoryName = Server.HtmlDecode(Category.Text);

   18 

   19         ListManager lists = new ListManager();

   20 

   21         for (int i = 0; i < numItemsToAdd; i++) {





== Collapsible Panel

5/2006 - uses the syntax [Drop#] .. 

[Drop#001## View the code]
   14     protected void Button1_Click(object sender, EventArgs e) {

   15 

   16         int numItemsToAdd = Int32.Parse(NumAdd.Text);

   17         string categoryName = Server.HtmlDecode(Category.Text);

   18 

   19         ListManager lists = new ListManager();

   20 

   21         for (int i = 0; i < numItemsToAdd; i++) {



[/Drop]

[4]

== NEW bullet list (using the >* notation)
>*Level 1
>>*Level 2
>>>*Level 3
>>>>*Level 4
>>>*Level 3
>>*Level 2
>*Level 1



----
[1] This page was revised to reflect changes by  ElreyRonald.
[2] A sample footnote. Clicking on this link takes you back and forth between the text and footnote.
[3] This is not standard in C2.com wiki but implemented in most engines.  Useful for other languages like German.

PrevPageData:
@@@@@@@@@@@@@@@@9/13/2012 4:41:37 PM : 10.240.2.79@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

==Table of Contents
[[TOC]]
== Creating a new Wiki page
>'''Method 1'''. Writing a Wiki''''''Word automatically creates a link to an editable the page.
 * Edit a page (by Edit button or by double clicking a page)
 * Simply type any WikiWord ( which is a joined capitalized word like-> ThisIsWikiWord ) in the page and click Save. 
 * The WikiWord becomes a hyperlink to create a new page.
 Examples:  ThisIsWikiPage,  MyVacation,  MyAlbumIn2005
This method is currently disabled. Wiki Links must be specific.

>'''Method 2'''. Use  [''''''[  and  ]''''''] to enclose just about any  page topic
 Examples:  [''''''[The Old Wise Man of Fantasia]'''''']
            [''''''[2006-02-15 Birth of my cousin]'''''']
>'''Method 3'''. Use  [''''''=  and  ]  works similar to method 2
 Examples:  [''''''=The Old Wise Man of Fantasia]
            [''''''=2006-02-15 Birth of my cousin]

== Basic Formatting   

'''Paragraphs''' [1]
 * '''Avoid indenting''' paragraphs.
 * '''Use blank lines''' to separate paragraphs.
 * You can use {'''br'''} to insert line break within a paragraph.   {red}'''NEW'''!{/red}

'''Monospace'''
	* Starting a line with space makes the whole line monospaced.
 This is an example of a monospaced line.

'''Lists'''
 * This is unnumbered list using '''space-asterisk''' 
 * You can also use '''tab-space'''. (If you can't type a TAB, use 8 spaces).  Or better yet just use  1 space.

Numbered List example:

 :* This is numbered list using '''tab-colon-asterisk'''.
 :* You can start a line with <space>:*<space>  
 :* or <space>:*<space> or <space>1.<space>  for lists.


'''Horizontal Line'''
	* Four dashes at the left margin: ''''''--''''''--

'''Emphasis'''
	* Use doubled single-quotes ('') for emphasis (usually italics)
	* Use tripled single-quotes (''') for strong emphasis (usually bold)
	* Use five single-quotes ('''''), or triples within doubles, for some other emphasis 
	* Use Six single-quotes, or triples within triples, to Break''''''Up Long''''''Bumpy''''''Words so that they do not become Wiki Name''''''s.
	* You can also use them to separate suffixes (like 's') from Wiki Name''''''s.  
	* Emphasis can be used multiple times within a line, but cannot cross line boundaries.
	* Use "-''_''" and "''_''-" for  -_underlining_-.

'''References'''
	* JoinCapitalizedWords to make local references. If the page is NOT YET created the link will LookLikeThis.
	* You can also use '''double brackets''' to create wiki words, for example, the format would be  '''[['''Wiki Word''']]''' [3]
	* Precede URLs with "http:" to create links automatically as in: http://www.c2.com/ 
	* Other kinds of links are mailto:my@email.com, ftp://www.ftp.com, news://ggroup.com
	* ISBN and Amazon(c) book link, use ISBN'':''0672320681 for example ISBN:0672320681

'''Imbedded Images'''
 * Imbedded images preceding url with '''img:''' like this:
  img''':'''http''':'''//c2.com/sig/wiki.gif  or image''':'''http''':'''//c2.com/sig/wiki.gif
img:http://c2.com/sig/wiki.gif 

'''Referencing files relative to the document root. (Local reference shortcut) {red}NEW!!12/2005{/red}'''
 * Note: '''local''': is not followed by slash characters.  For example, writing...
 1. link local file examples  
 
   writing... {blue}local'''''':wiki.css{/blue}      results to this link ->  local:wiki.css
   writing... {blue}local'''''':icon.png{/blue}      results to this link-->  local:icon.png
   If file is sub folder , simply write like this --> {blue}local'''''':images\icons\icon.png{/blue} 

 2. local image extensions

   The keyword $''''''image$ results in a reference to local'''''':images/page_Current''''''Page''''''Name. This allows each page to have a directory of local images.
   The keyword $''''''Page$ results in the name of the current page

 3. local image examples    
 
   writing... {blue}image'''''':local:icon.png{/blue} results to this --> image:local:icon.png  
   writing... {blue}imageleft'''''':local:icon.png and  imageright'''''':local:icon.png{/blue} work as follows...
imageleft:local:icon.png  
imageright:local:icon.png

{br}
'''Footnotes'''
	* You can use numeric and square bracket for a footnote. [2]
	* At the bottom, just add square bracket at first character of a line and the number.

== Other Types of Formatting
	* Three blank lines creates 1 blank line
	* '==','===','====' at the start of line creates Topic
	* Coloring text for {red}red{/red}, {green}green{/green}, {blue}blue{/blue} and {black}black{/black} are allowed but must be kept at minimum.  Remember wiki is not about fancy presentation but more about quality content.
	* Use ">" to indent a paragraph (first level).   You can  also use ">>" for second level. ">>>" for third level indentation or block quote. ''' Formerly, the pipe character '|' was used for this purpose.'''  Pipe character is now used for tables. see below.
	* Use also '''{'''italic'''}''' or '''{'''bold'''}''' to {italic}highlight longer texts or paragraphs.{/italic}
	* Precede url with image with  '''Imageleft:''' or '''Imageright:'''  or '''Imagecenter:'''to justify image.

== Alternate Labels to Links and Wiki Words
 * Use alternate label to hide URL or hyperlink  like this...
 #@91;Go to Cnn News|http''''''://cnn.com#@93;
yields this...   [Go to Cnn News|http://cnn.com] !!!
 * Use alternate label to hide WikiWord like this:  
 #@91;Go to my Wiki homepage=wikiasp#@93;
yields this...
[Go to my Wiki homepage=Wikiasp] !!!

== InterWiki Links
Examples:
 #@91;My Website=ElreySite::Vacation''''''Page#@93;   -> ''Goes to the page VacationPage of database ElreySite using My Website as link alias.''
 #@91;My Website=Elrey''''''Site::#@93;               -> ''Goes to default start page of database ElreySite using My Website as link alias.'' 
 #@91;Elrey''''''Site::Vacation''''''Page#@93;              -> ''Goes to the page VacationPage of database ElreySite using no link alias.''
 #@91;Elrey''''''Site::#@93;                          -> ''Goes to default start page of database ElreySite using no link alias.''

== Table of Contents
Each page may contain a Table of Contents. It will be calculated based on the Top Level Tops that start with a space that are found at the beginning of a line. ie ''''''== Name 

The table will be inserted in the output to replace a line that starts with [''''''[TOC]''''''].

== Clickable Images
 * Use same technique above to create clickable (note the space aroung the img link)
 #@91; img'''''':http''''''://c2.com/sig/wiki.gif |http''''''://c2.com#@93;
yields this...
[ img:http://c2.com/sig/wiki.gif |http://c2.com]

== Tables
 * {red}'''NEW'''!{/red} - Use '||' character to construct tables.  Each row can have a color scheme by using '|!', '!|', or '!!'. Each row need not end with '||'. For example

|| This is || Ordinary Row || a New WikiAsp Feature
!| This color scheme || Sample || One
|! This color scheme || Sample || Two
!! This color scheme || Sample || Three
|| Great feature 

|! S|| M|| T|| W|| T|| F|| S
||  ||  || 1|| 2|| 3|| 4|| 5
|| 6|| 7|| 8|| 9||10||11||12
||13||14||15||16||17||18||19
||20||21||22||23||24||25||26
||27||28||29||30||31||  || 

== Sample HTML ({red}'''NEW'''!{/red})

If you know HTML, you can also enter it and tailor your wiki pages to your heart's desire.

>This is useful for imbedding Source Code and programs.  [Search Google for the utility|http://www.google.com/search?q=CopySourceAsHTML]


   22     <microsoft.web>

   23         <converters>

   24             <add type="Microsoft.Web.Script.Serialization.Converters.DataSetConverter"/>

   25             <add type="Microsoft.Web.Script.Serialization.Converters.DataRowConverter"/>

   26             <add type="Microsoft.Web.Script.Serialization.Converters.DataTableConverter"/>

   27         </converters>

   28     </microsoft.web>

   29     <appSettings/>





>CopySourceAsHTML is a utility that preserves syntax coloring



    9 using System.Web.UI.WebControls.WebParts;

   10 using System.Web.UI.HtmlControls;

   11 

   12 public partial class AddData : System.Web.UI.Page {

   13 

   14     protected void Button1_Click(object sender, EventArgs e) {

   15 

   16         int numItemsToAdd = Int32.Parse(NumAdd.Text);

   17         string categoryName = Server.HtmlDecode(Category.Text);

   18 

   19         ListManager lists = new ListManager();

   20 

   21         for (int i = 0; i < numItemsToAdd; i++) {





== Collapsible Panel

5/2006 - uses the syntax [Drop#] .. 

[Drop#001## View the code]
   14     protected void Button1_Click(object sender, EventArgs e) {

   15 

   16         int numItemsToAdd = Int32.Parse(NumAdd.Text);

   17         string categoryName = Server.HtmlDecode(Category.Text);

   18 

   19         ListManager lists = new ListManager();

   20 

   21         for (int i = 0; i < numItemsToAdd; i++) {



[/Drop]

[4]

== NEW bullet list (using the >* notation)
>*Level 1
>>*Level 2
>>>*Level 3
>>>>*Level 4
>>>*Level 3
>>*Level 2
>*Level 1



----
[1] This page was revised to reflect changes by  ElreyRonald.
[2] A sample footnote. Clicking on this link takes you back and forth between the text and footnote.
[3] This is not standard in C2.com wiki but implemented in most engines.  Useful for other languages like German.

@@@@@@@@@@@@@@@@9/13/2012 4:37:41 PM : 10.240.2.79@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

==Table of Contents
[[TOC]]
== Creating a new Wiki page
>'''Method 1'''. Writing a Wiki''''''Word automatically creates a link to an editable the page.
 * Edit a page (by Edit button or by double clicking a page)
 * Simply type any WikiWord ( which is a joined capitalized word like-> ThisIsWikiWord ) in the page and click Save. 
 * The WikiWord becomes a hyperlink to create a new page.
 Examples:  ThisIsWikiPage,  MyVacation,  MyAlbumIn2005
>'''Method 2'''. Use  [''''''[  and  ]''''''] to enclose just about any  page topic
 Examples:  [''''''[The Old Wise Man of Fantasia]'''''']
            [''''''[2006-02-15 Birth of my cousin]'''''']
>'''Method 3'''. Use  [''''''=  and  ]  works similar to method 2
 Examples:  [''''''=The Old Wise Man of Fantasia]
            [''''''=2006-02-15 Birth of my cousin]

== Basic Formatting   

'''Paragraphs''' [1]
 * '''Avoid indenting''' paragraphs.
 * '''Use blank lines''' to separate paragrap


PageData:
==Summary of Changes
[[TOC]]
== Add Missing Dependency
It is now possible to easily add a missing dependency.
The dependencies page now displays a new clickable icon against missing packages in the dependency list.
See the figure below.  The new clickable icon is circled in red.

image:$image$/missing_depen_list.JPG

When clicked a new form is opened showing the dependency details which also allows the destination view to be selected.
See the figure below.

image:$image$/missing_depen_form.JPG

When added, the dependency is added to the released list of packages.
Dependencies of the missing dependency are not added.  It is the user’s responsibility to add these dependencies.

== Subversion Tag Usage Improvement for New Package
A new field has been added to the release notes tab for packages that use SubVersion as the version control system.
This new field is, "WIP Tag", and will show the WIP part of the full subversion tag.

The full Subversion Tag, that is already displayed, shows:
 project directory/branches/WIP tag

The new WIP Tag field will just show
 WIP tag

See the figure below.

image:$image$/wip_tag.JPG

Note: This field will be displayed for WIPs that use subversion only.

This new WIP tag facilitates JATS command line operations as it can be directly used by JATS.
The user just needs to cut the WIP Tag and paste it into a Jats command line.

== Subversion Tag Sanity Check
The validation rules of the SVN Tag of the Package Information form have been improved to not allow subversion tags that end in /trunk.

== Release Summary Status Improvement
A new daemon status column has now been added to the release page to provide a clear view of the status of daemons associated to each release of a project.
This new column displays a component that conveys the daemon's status in a very effective way with a set of icons. Each daemon is represented by an LED icon.  Indicating the following:

 * Running daemons
 * Running daemons engaged in a build
 * Running daemons timed out       
 * Paused daemons
 * Stopped daemons
 * Daemons indefinitely paused
 * Daemons not available
The new column is illustrated below.

image:$image$/dmstat_rel.JPG

Other enhancements to this page are:
 * A new column, "Created", has been added to show the creation timestamp and the creator. It is very useful to know the creator of a release.
 * The column "Associated MASS_REF" has been removed.
These enhancements are also illustrated in the above figure.

== Package Version Status Improvement
Another significant improvement is that the package version page has been modified to effectively convey the package version status with a new set of icons.

The package version status indication in the previous system only indicated that the package is locked (released). This has been extended to include:

 * Package is a work in progress
 * Package ready to build, however at least one dependency has been superseded with a major or minor version
 * Package ready to build, however at least one dependency has been superseded with a patch version
 * Package not ready to be built. Dependent packages, with a major or minor version, require building
 * Package not ready to be built. Dependent packages, with a patch version, require building
 * Package is deprecated
 * Package depends on a deprecated package
 * Package is pegged
 * Package is marked as advisory ripple
 * Package is unlocked
 * Package pending
 * Package has pending daemon instruction
 * Package excluded from build
 * Package failed to build
 * Package is manually versioned

An example of some of these new status icons is illustrated below.  They are circled in red.

image:$image$/pkg_stat.JPG

For a full list of icons, view the "Icon Legend" link.  This link is circled in red in the following figure.

image:$image$/pkg_stat_icon_link.JPG

Some other useful enhancements are:
The daemon status component has also been added to the package version page.
It is illustrated below.  It is shown in the top left part of this figure.

image:$image$/dmstat_pkg.JPG

The build status page now highlights timed-out daemons.  The "Last Change Delta" column, for timed-out daemons, is displayed in red text as shown below.

image:$image$/dmstat_bld.JPG

Pending packages that are listed in the view pane of the package version page are now indicated with a new icon.
See the figure below.  It is circled in red.

image:$image$/pkg_pend.JPG

== Re-locking Capability
The Re-locking capability of the "Release Notes" tab has been improved.

Two new buttons for unlocking and locking of a package have been added to the set of buttons on the package page.
See the figure below.

image:$image$/re-lock.JPG

'''Note: These buttons will be enabled for Administrators only'''

PrevPageData:
@@@@@@@@@@@@@@@@9/12/2012 4:51:23 PM : 10.240.2.79@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

== Add Missing Dependency
It is now possible to easily add a missing dependency.
The dependencies page now displays a new clickable icon against missing packages in the dependency list.
See the figure below.  The new clickable icon is circled in red.

image:$image$/missing_depen_list.JPG

When clicked a new form is opened showing the dependency details which also allows the destination view to be selected.
See the figure below.

image:$image$/missing_depen_form.JPG

When added, the dependency is added to the released list of packages.
Dependencies of the missing dependency are not added.  It is the user’s responsibility to add these dependencies.

== Subversion Tag Usage Improvement for New Package
A new field has been added to the release notes tab for packages that use SubVersion as the version control system.
This new field is, "WIP Tag", and will show the WIP part of the full subversion tag.

The full Subversion Tag, that is already displayed, shows:
 project directory/branches/WIP tag

The new WIP Tag field will just show
 WIP tag

See the figure below.

image:$image$/wip_tag.JPG

Note: This field will be displayed for WIPs that use subversion only.

This new WIP tag facilitates JATS command line operations as it can be directly used by JATS.
The user just needs to cut the WIP Tag and paste it into a Jats command line.


== Subversion Tag Sanity Check
The validation rules of the SVN Tag of the Package Information form have been improved to not allow subversion tags that end in /trunk.


===Release Summary Status Improvement
A new daemon status column has now been added to the release page to provide a clear view of the status of daemons associated to each release of a project.
This new column displays a component that conveys the daemon's status in a very effective way with a set of icons. Each daemon is represented by an LED icon.  Indicating the following:

 * Running daemons
 * Running daemons engaged in a build
 * Running daemons timed out       
 * Paused daemons
 * Stopped daemons
 * Daemons indefinitely paused
 * Daemons not available
The new column is illustrated below.

image:$image$/dmstat_rel.JPG

Other enhancements to this page are:
 * A new column, "Created", has been added to show the creation timestamp and the creator. It is very useful to know the creator of a release.
 * The column "Associated MASS_REF" has been removed.
These enhancements are also illustrated in the above figure.


===Package Version Status Improvement
Another significant improvement is that the package version page has been modified to effectively convey the package version status with a new set of icons.

The package version status indication in the previous system only indicated that the package is locked (released). This has been extended to include:

 * Package is a work in progress
 * Package ready to build, however at least one dependency has been superseded with a major or minor version
 * Package ready to build, however at least one dependency has been superseded with a patch version
 * Package not ready to be built. Dependent packages, with a major or minor version, require building
 * Package not ready to be built. Dependent packages, with a patch version, require building
 * Package is deprecated
 * Package depends on a deprecated package
 * Package is pegged
 * Package is marked as advisory ripple
 * Package is unlocked
 * Package pending
 * Package has pending daemon instruction
 * Package excluded from build
 * Package failed to build
 * Package is manually versioned

An example of some of these new status icons is illustrated below.  They are circled in red.

image:$image$/pkg_stat.JPG

For a full list of icons, view the "Icon Legend" link.  This link is circled in red in the following figure.

image:$image$/pkg_stat_icon_link.JPG

Some other useful enhancements are:
The daemon status component has also been added to the package version page.
It is illustrated below.  It is shown in the top left part of this figure.

image:$image$/dmstat_pkg.JPG

The build status page now highlights timed-out daemons.  The "Last Change Delta" column, for timed-out daemons, is displayed in red text as shown below.

image:$image$/dmstat_bld.JPG

Pending packages that are listed in the view pane of the package version page are now indicated with a new icon.
See the figure below.  It is circled in red.

image:$image$/pkg_pend.JPG

=== Re-locking Capability
The Re-locking capability of the "Release Notes" tab has been improved.

Two new buttons for unlocking and locking of a package have been added to the set of buttons on the package page.
See the figure below.

image:$image$/re-lock.JPG

'''Note: These buttons will be enabled for Administrators only'''



@@@@@@@@@@@@@@@@9/12/2012 2:11:01 PM : 10.240.2.79@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

== Summary of Changes
 *Add Missing Dependency
 *Subversion Tag Usage Improvement for New Package
 *Subversion Tag Sanity Check
 *Release Summary Status Improvement
 *Package Version Status Improvement
 *Re-locking Capability
=== Add Missing Dependency
It is now possible to easily add a missing dependency.
The dependencies page now displays a new clickable icon against missing packages in the dependency list.
See the figure below.  The new clickable icon is circled in red.

image:$image$/missing_depen_list.JPG

When clicked a new form is opened showing the dependency details which also allows the destination view to be selected.
See the figure below.

image:$image$/missing_depen_form.JPG

When added, the dependency is added to the released list of packages.
Dependencies of the missing dependency are not added.  It is the user’s responsibility to add these dependencies.

=== Subversion Tag Usage Improvement for New Package
A new field has been added to the release notes tab for packages that use SubVersion as the version control system.
This new field is, "WIP Tag", and will show the WIP part of the full subversion tag.

The full Subversion Tag, that is already displayed, shows:
 project directory/branches/WIP tag

The new WIP Tag field will just show
 WIP tag

See the figure below.

image:$image$/wip_tag.JPG

Note: This field will be displayed for WIPs that use subversion only.

This new WIP tag facilitates JATS command line operations as it can be directly used by JATS.
The user just needs to cut the WIP Tag and paste it into a Jats command line.


=== Subversion Tag Sanity Check
The validation rules of the SVN Tag of the Package Information form have been improved to not allow subversion tags that end in /trunk.


===Release Summary Status Improvement
A new daemon status column has now been added to the release page to provide a clear view of the status of daemons associated to each release of a project.
This new column displays a component that conveys the daemon's status in a very effective way with a set of icons. Each daemon is represented by an LED icon.  Indicating the following:

 * Running daemons
 * Running daemons engaged in a build
 * Running daemons timed out       
 * Paused daemons
 * Stopped daemons
 * Daemons indefinitely paused
 * Daemons not available
The new column is illustrated below.

image:$image$/dmstat_rel.JPG

Other enhancements to this page are:
 * A new column, "Created", has been added to show the creation timestamp and the creator. It is very useful to know the creator of a release.
 * The column "Associated MASS_REF" has been removed.
These enhancements are also illustrated in the above figure.


===Package Version Status Improvement
Another significant improvement is that the package version page has been modified to effectively convey the package version status with a new set of icons.

The package version status indication in the previous system only indicated that the package is locked (released). This has been extended to include:

 * Package is a work in progress
 * Package ready to build, however at least one dependency has been superseded with a major or minor version
 * Package ready to build, however at least one dependency has been superseded with a patch version
 * Package not ready to be built. Dependent packages, with a major or minor version, require building
 * Package not ready to be built. Dependent packages, with a patch version, require building
 * Package is deprecated
 * Package depends on a deprecated package
 * Package is pegged
 * Package is marked as advisory ripple
 * Package is unlocked
 * Package pending
 * Package has pending daemon instruction
 * Package excluded from build
 * Package failed to build
 * Package is manually versioned

An example of some of these new status icons is illustrated below.  They are circled in red.

image:$image$/pkg_stat.JPG

For a full list of icons, view the "Icon Legend" link.  This link is circled in red in the following figure.

image:$image$/pkg_stat_icon_link.JPG

Some other useful enhancements are:
The daemon status component has also been added to the package version page.
It is illustrated below.  It is shown in the top left part of this figure.

image:$image$/dmstat_pkg.JPG

The build status page now highlights timed-out daemons.  The "Last Change Delta" column, for timed-out daemons, is displayed in red text as shown below.

image:$image$/dmstat_bld.JPG

Pending packages that are listed in the view pane of the package version page are now indicated with a new icon.
See the figure below.  It is circled in red.

image:$image$/pkg_pend.JPG

=== Re-locking Capability
The Re-locking capability of the "Release Notes" tab has been improved.

Two new buttons for unlocking and locking of a package have been added to the set of buttons on the package page.
See the figure below.

image:$image$/re-lock.JPG

'''Note: These buttons will be enabled for Administrators only'''



@@@@@@@@@@@@@@@@9/12/2012 10:22:05 AM : 10.240.2.79@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

Go back to [[ReleaseManager]] page

== Summary of Changes
 *Add Missing Dependency
 *Subversion Tag Usage Improvement for New Package
 *Subversion Tag Sanity Check
 *Release Summary Status Improvement
 *Package Version Status Improvement
 *Re-locking Capability
=== Add Missing Dependency
It is now possible to easily add a missing dependency.
The dependencies page now displays a new clickable icon against missing packages in the dependency list.
See the figure below.  The new clickable icon is circled in red.

image:$image$/missing_depen_list.JPG

When clicked a new form is opened showing the dependency details which also allows the destination view to be selected.
See the figure below.

image:$image$/missing_depen_form.JPG

When added, the dependency is added to the released list of packages.
Dependencies of the missing dependency are not added.  It is the user’s responsibility to add these dependencies.

=== Subversion Tag Usage Improvement for New Package
A new field has been added to the release notes tab for packages that use SubVersion as the version control system.
This new field is, "WIP Tag", and will show the WIP part of the full subversion tag.

The full Subversion Tag, that is already displayed, shows:
 project directory/branches/WIP tag

The new WIP Tag field will just show
 WIP tag

See the figure below.

image:$image$/wip_tag.JPG

Note: This field will be displayed for WIPs that use subversion only.

This new WIP tag facilitates JATS command line operations as it can be directly used by JATS.
The user just needs to cut the WIP Tag and paste it into a Jats command line.


=== Subversion Tag Sanity Check
The validation rules of the SVN Tag of the Package Information form have been improved to not allow subversion tags that end in /trunk.


===Release Summary Status Improvement
A new daemon status column has now been added to the release page to provide a clear view of the status of daemons associated to each release of a project.
This new column displays a component that conveys the daemon's status in a very effective way with a set of icons. Each daemon is represented by an LED icon.  Indicating the following:

 * Running daemons
 * Running daemons engaged in a build
 * Running daemons timed out       
 * Paused daemons
 * Stopped daemons
 * Daemons indefinitely paused
 * Daemons not available
The new column is illustrated below.

image:$image$/dmstat_rel.JPG

Other enhancements to this page are:
 * A new column, "Created", has been added to show the creation timestamp and the creator. It is very useful to know the creator of a release.
 * The column "Associated MASS_REF" has been removed.
These enhancements are also illustrated in the above figure.


===Package Version Status Improvement
Another significant improvement is that the package version page has been modified to effectively convey the package version status with a new set of icons.

The package version status indication in the previous system only indicated that the package is locked (released). This has been extended to include:

 * Package is a work in progress
 * Package ready to build, however at least one dependency has been superseded with a major or minor version
 * Package ready to build, however at least one dependency has been superseded with a patch version
 * Package not ready to be built. Dependent packages, with a major or minor version, require building
 * Package not ready to be built. Dependent packages, with a patch version, require building
 * Package is deprecated
 * Package depends on a deprecated package
 * Package is pegged
 * Package is marked as advisory ripple
 * Package is unlocked
 * Package pending
 * Package has pending daemon instruction
 * Package excluded from build
 * Package failed to build
 * Package is manually versioned

An example of some of these new status icons is illustrated below.  They are circled in red.

image:$image$/pkg_stat.JPG

For a full list of icons, view the "Icon Legend" link.  This link is circled in red in the following figure.

image:$image$/pkg_stat_icon_link.JPG

Some other useful enhancements are:
The daemon status component has also been added to the package version page.
It is illustrated below.  It is shown in the top left part of this figure.

image:$image$/dmstat_pkg.JPG

The build status page now highlights timed-out daemons.  The "Last Change Delta" column, for timed-out daemons, is displayed in red text as shown below.

image:$image$/dmstat_bld.JPG

Pending packages that are listed in the view pane of the package version page are now indicated with a new icon


PageData:
==Summary of Changes
[[TOC]]
== Configurable Archive Server
The archive server can now be configured within the "Build Service Configuration" form.
In the previous version this was set to a fixed value, which did not allow changes to the archive location.
 
A new entry has been added to this form called, ARCHIVE SERVER.
This is illustrated below.

image:$image$/bld_svc.JPG

This form is accessed from the Admin | Build Service menu item.  As shown below:

image:$image$/menu_access.JPG

Also, the "MUTEX" and "WEB SERVER" fields of the "Build Service Configuration" form are no longer displayed as they have no display purpose.

The "Build Status Information" form has been enhanced so that it no longer contains hard coded links to the archive server.
The links now use the archive server configured in the "Build Service Configuration" form.

Another important improvement that was made is that these links now use a http url so that the buildlog file can be viewed
by all browsers not just firefox as was the case in the previous system.
As a result, the Note, "firefox users", in the "ROOT CAUSES" header of the "Build Status Information" form has been removed. 

The following were also modified to use the configured archive server:
 * The file links listed in the "Files and Folder" tab.
 * The Release Notes download link in the "Release Notes" tab
 * The Unit test result url
 * The "View by Files" process when listing links to found files.
 * The "Advanced Search" process when listing links to found files.
 * The Make Release process scripts


== Displaying the Build Service Admin Page to normal users
The Build Service Admin Page has been enhanced so that it is displayed in readonly mode for normal users.
In the previous system normal users were unable to see this page.  This is illustrated below.

image:$image$/bld_svc_dis.JPG

This allows normal uses to view the important information available in the "Build Service Configuration" and "Run Level Schedule" forms.

Normal users can access this form from the Admin | Build Service menu item.  As follows:

image:$image$/menu_normal.JPG


== The automated build system now logs an action when re-building a package
This indicates that a package may have been deleted from the package archive or the package
may have been manually versioned and built by the daemons.

== Corrected an issue with the Un-release package process
This process wasn't properly clearing the package database settings.

== Corrected an issue with Clear''''''Quest and Jira database access
The connection string details for these databases were modified as they now reside on a new server.

PrevPageData:
@@@@@@@@@@@@@@@@9/12/2012 5:51:41 PM : 10.240.2.79@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

==Summary of Changes
[[TOC]]
== Configurable Archive Server
The archive server can now be configured within the "Build Service Configuration" form.
In the previous version this was set to a fixed value, which did not allow changes to the archive location.
 
A new entry has been added to this form called, ARCHIVE SERVER.
This is illustrated below.

image:$image$/bld_svc.JPG

This form is accessed from the Admin | Build Service menu item.  As shown below:

image:$image$/menu_access.JPG


Also, the "MUTEX" and "WEB SERVER" fields of the "Build Service Configuration" form are no longer displayed as they have no display purpose.

The "Build Status Information" form has been enhanced so that it no longer contains hard coded links to the archive server.
The links now use the archive server configured in the "Build Service Configuration" form.

Another important improvement that was made is that these links now use a http url so that the buildlog file can be viewed
by all browsers not just firefox as was the case in the previous system.
As a result, the Note, "firefox users", in the "ROOT CAUSES" header of the "Build Status Information" form has been removed. 


The following were also modified to use the configured archive server:
 * The file links listed in the "Files and Folder" tab.
 * The Release Notes download link in the "Release Notes" tab
 * The Unit test result url
 * The "View by Files" process when listing links to found files.
 * The "Advanced Search" process when listing links to found files.
 * The Make Release process scripts


== Displaying the Build Service Admin Page to normal users
The Build Service Admin Page has been enhanced so that it is displayed in readonly mode for normal users.
In the previous system normal users were unable to see this page.  This is illustrated below.

image:$image$/bld_svc_dis.JPG

This allows normal uses to view the important information available in the "Build Service Configuration" and "Run Level Schedule" forms.

Normal users can access this form from the Admin | Build Service menu item.  As follows:

image:$image$/menu_normal.JPG


== The automated build system now logs an action when re-building a package

== Corrected an issue with the Un-release package process
This process wasn't properly clearing the package database settings.


== Corrected an issue with Clear''''''Quest and Jira database access
The connection string details for these databases were modified as they now reside on a new server.


@@@@@@@@@@@@@@@@9/12/2012 4:49:16 PM : 10.240.2.79@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

== Configurable Archive Server
The archive server can now be configured within the "Build Service Configuration" form.
In the previous version this was set to a fixed value, which did not allow changes to the archive location.
 
A new entry has been added to this form called, ARCHIVE SERVER.
This is illustrated below.

image:$image$/bld_svc.JPG

This form is accessed from the Admin | Build Service menu item.  As shown below:

image:$image$/menu_access.JPG


Also, the "MUTEX" and "WEB SERVER" fields of the "Build Service Configuration" form are no longer displayed as they have no display purpose.

The "Build Status Information" form has been enhanced so that it no longer contains hard coded links to the archive server.
The links now use the archive server configured in the "Build Service Configuration" form.

Another important improvement that was made is that these links now use a http url so that the buildlog file can be viewed
by all browsers not just firefox as was the case in the previous system.
As a result, the Note, "firefox users", in the "ROOT CAUSES" header of the "Build Status Information" form has been removed. 


The following were also modified to use the configured archive server:
 * The file links listed in the "Files and Folder" tab.
 * The Release Notes download link in the "Release Notes" tab
 * The Unit test result url
 * The "View by Files" process when listing links to found files.
 * The "Advanced Search" process when listing links to found files.
 * The Make Release process scripts


== Displaying the Build Service Admin Page to normal users
The Build Service Admin Page has been enhanced so that it is displayed in readonly mode for normal users.
In the previous system normal users were unable to see this page.  This is illustrated below.

image:$image$/bld_svc_dis.JPG

This allows normal uses to view the important information available in the "Build Service Configuration" and "Run Level Schedule" forms.

Normal users can access this form from the Admin | Build Service menu item.  As follows:

image:$image$/menu_normal.JPG


== The automated build system now logs an action when re-building a package

== Corrected an issue with the Un-release package process
This process wasn't properly clearing the package database settings.


== Corrected an issue with Clear''''''Quest and Jira database access
The connection string details for these databases were modified as they now reside on a new server.



@@@@@@@@@@@@@@@@9/12/2012 4:49:02 PM : 10.240.2.79@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

== Summary of Changes
 * Configurable Archive Server
 * Displaying the Build Service Admin Page to normal users
 * The automated build system now logs an action when re-building a package
 * Corrected an issue with the Un-release package process
 * Corrected an issue with Clear''''''Quest and Jira database access

== Configurable Archive Server
The archive server can now be configured within the "Build Service Configuration" form.
In the previous version this was set to a fixed value, which did not allow changes to the archive location.
 
A new entry has been added to this form called, ARCHIVE SERVER.
This is illustrated below.

image:$image$/bld_svc.JPG

This form is accessed from the Admin | Build Service menu item.  As shown below:

image:$image$/menu_access.JPG


Also, the "MUTEX" and "WEB SERVER" fields of the "Build Service Configuration" form are no longer displayed as they have no display purpose.

The "Build Status Information" form has been enhanced so that it no longer contains hard coded links to the archive server.
The links now use the archive server configured in the "Build Service Configuration" form.

Another important improvement that was made is that these links now use a http url so that the buildlog file can be viewed
by all browsers not just firefox as was the case in the previous system.
As a result, the Note, "firefox users", in the "ROOT CAUSES" header of the "Build Status Information" form has been removed. 


The following were also modified to use the configured archive server:
 * The file links listed in the "Files and Folder" tab.
 * The Release Notes download link in the "Release Notes" tab
 * The Unit test result url
 * The "View by Files" process when listing links to found files.
 * The "Advanced Search" process when listing links to found files.
 * The Make Release process scripts


== Displaying the Build Service Admin Page to normal users
The Build Service Admin Page has been enhanced so that it is displayed in readonly mode for normal users.
In the previous system normal users were unable to see this page.  This is illustrated below.

image:$image$/bld_svc_dis.JPG

This allows normal uses to view the important information available in the "Build Service Configuration" and "Run Level Schedule" forms.

Normal users can access this form from the Admin | Build Service menu item.  As follows:

image:$image$/menu_normal.JPG


== The automated build system now logs an action when re-building a package

== Corrected an issue with the Un-release package process
This process wasn't properly clearing the package database settings.


== Corrected an issue with Clear''''''Quest and Jira database access
The connection string details for these databases were modified as they now reside on a new server.



@@@@@@@@@@@@@@@@9/12/2012 10:58:11 AM : 10.240.2.79@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

Go back to [[ReleaseManager]] page

== Summary of Changes
 * Configurable Archive Server
 * Displaying the Build Service Admin Page to normal users
 * The automated build system now logs an action when re-building a package
 * Corrected an issue with the Un-release package process
 * Corrected an issue with Clear''''''Quest and Jira database access

===Configurable Archive Server
The archive server can now be configured within the "Build Service Configuration" form.
In the previous version this was set to a fixed value, which did not allow changes to the archive location.
 
A new entry has been added to this form called, ARCHIVE SERVER.
This is illustrated below.

image:$image$/bld_svc.JPG

This form is accessed from the Admin | Build Service menu item.  As shown below:

image:$image$/menu_access.JPG


Also, the "MUTEX" and "WEB SERVER" fields of the "Build Service Configuration" form are no longer displayed as they have no display purpose.

The "Build Status Information" form has been enhanced so that it no longer contains hard coded links to the archive server.
The links now use the archive server configured in the "Build Service Configuration" form.

Another important improvement that was made is that these links now use a http url so that the buildlog file can be viewed
by all browsers not just firefox as was the case in the previous system.
As a result, the Note, "firefox users", in the "ROOT CAUSES" header of the "Build Status Information" form has been removed. 


The following were also modified to use the configured archive server:
 * The file links listed in the "Files and Folder" tab.
 * The Release Notes download link in the "Release Notes" tab
 * The Unit test result url
 * The "View by Files" process when listing links to found files.
 * The "Advanced Search" process when listing links to found files.
 * The Make Release process scripts


===Displaying the Build Service Admin Page to normal users
The Build Service Admin Page has been enhanced so that it is displayed in readonly mode for normal users.
In the previous system normal users were unable to see this page.  This is illustrated below.

image:$image$/bld_svc_dis.JPG

This allows normal uses to view the important information available in the "Build Service Configuration" and "Run Level Schedule" forms.

Normal users can access this form from the Admin | Build Service menu item.  As follows:

image:$image$/menu_normal.JPG


===The automated build system now logs an action when re-building a package

===Corrected an issue with the Un-release package process
This process wasn't properly clearing the package database settings.


===Corrected an issue with Clear''''''Quest and Jira database access
The connection string details for these databases were modified as they now reside on a new server.



@@@@@@@@@@@@@@@@9/12/2012 10:42:38 AM : 10.240.2.79@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

Go back to [[ReleaseManager]] page

[{TableOfContents}]

===Configurable Archive Server
The archive server can now be configured within the "Build Service Configuration" form.
In the previous version this was set to a fixed value, which did not allow changes to the archive location.
 
A new entry has been added to this form called, ARCHIVE SERVER.
This is illustrated below.

image:$image$/bld_svc.JPG

This form is accessed from the Admin | Build Service menu item.  As shown below:

image:$image$/menu_access.JPG


Also, the "MUTEX" and "WEB SERVER" fields of the "Build Service Configuration" form are no longer displayed as they have no display purpose.

The "Build Status Information" form has been enhanced so that it no longer contains hard coded links to the archive server.
The links now use the archive server configured in the "Build Service Configuration" form.

Another important improvement that was made is that these links now use a http url so that the buildlog file can be viewed
by all browsers not just firefox as was the case in the previous system.
As a result, the Note, "firefox users", in the "ROOT CAUSES" header of the "Build Status Information" form has been removed. 


The following were also modified to use the configured archive server:
 * The file links listed in the "Files and Folder" tab.
 * The Release Notes download link in the "Release Notes" tab
 * The Unit test result url
 * The "View by Files" process when listing links to found files.
 * The "Advanced Search" process when listing links to found files.
 * The Make Release process scripts


===Displaying the Build Service Admin Page to normal users
The Build Service Admin Page has been enhanced so that it is displayed in readonly mode for normal users.
In the previous system normal users were unable to see this page.  This is illustrated below.

image:$image$/bld_svc_dis.JPG

This allows normal uses to view the important information available in the "Build Service Configuration" and "Run Level Schedule" forms.

Normal users can access this form from the Admin | Build Service menu item.  As follows:

image:$image$/menu_normal.JPG


===The automated build system now logs an action when re-building a package

===Corrected an issue with the Un-release package process
This process wasn't properly clearing the package database settings.


===Corrected an issue with ClearQuest and Jira database access
The connection string details for these databases were modified as they now reside on a new server.


PageData:
==Summary of Changes
[[TOC]]
== Release Notes
The Release Manager Release notes are no longer in the VIX Wiki. Release Notes are now served by the Release Manager itself.

Some of the Release Notes from the old Wiki have been migrated, but not all.

Release Notes are now served via a small ASP based Wiki. http://lambda.vze.com/. This may be the basis for improved Release Manger documentation.

== Subversion Path and Tag
The definition of the package source has been modified for a Subversion based package. The code is referenced via two values:

1. Source Path
{br}This is the Subversion path to the development branch of the package. The first element will be a symbolic repository reference.
{br}The last element will be the packages development branch - which may be the trunk.

2. Tag
{br}This is the a named directory within the packages 'tags' directory. It may be pegged.
{br}If the Tag is a simple number, then it will be treated as a peg of the Source Path.

image:$image$/Image1.png

== Subversion Extraction Commands
Release Manager will show Subversion specific extraction commands. The commands shown will depend on the state of the package.

If the package has been released, then Release Manager will show a single extraction command. This command will reproduce the package source in a workable workspace.

If the package has not yet been released, then Release Manager will show a number of different extraction commands. The use must select one command that will suit the intended use of the workspace. The commands allow for:
 * Default - suits most requirements.
 * Tag - Trace Tag back to development branch
 * Tip - Tip of the development branch
 * Work - Default
 * Exact - Extract the tagged instance
Other extraction commands may be shown to allow extraction of the previous version of the package.

image:$image$/Image3.png

== Daemon Status
The 'Build Daemon Status' page has been modified to:
>* Allow filtering of Disabled Daemons
>* Enhanced 'Last Change Delta': 
>>* If the time since the daemon was last seen as active is greater the an hour then the delta will be shown as the time that the daemons was last active.
>>* If the time is greater than a day, then the date of the last activity is shown.
>>* Disables daemons do not show up in red

image:$image$/Image2.png

PrevPageData:
@@@@@@@@@@@@@@@@9/12/2012 6:12:51 PM : 10.240.2.79@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

==Summary of Changes
[[TOC]]
== Release Notes
The Release Manager Release notes are no longer in the VIX Wiki. Release Notes are now served by the Release Manager itself.

Some of the Release Notes from the old Wiki have been migrated, but not all.

Release Notes are now served via a small ASP based Wiki. http://lambda.vze.com/

== Subversion Path and Tag
The definition of the package source has been modified for a Subversion based package. The code is referenced via two values:

1. Source Path
{br}This is the Subversion path to the development branch of the package. The first element will be a symbolic repository reference.
{br}The last element will be the packages development branch - which may be the trunk.

2. Tag
{br}This is the a named directory within the packages 'tags' directory. It may be pegged.
{br}If the Tag is a simple number, then it will be treated as a peg of the Source Path.

image:$image$/Image1.png

== Subversion Extraction Commands
Release Manager will show Subversion specific extraction commands. The commands shown will depend on the state of the package.

If the package has been released, then Release Manager will show a single extraction command. This command will reproduce the package source in a workable workspace.

If the package has not yet been released, then Release Manager will show a number of different extraction commands. The use must select one command that will suit the intended use of the workspace. The commands allow for:
 * Default - suits most requirements.
 * Tag - Trace Tag back to development branch
 * Tip - Tip of the development branch
 * Work - Default
 * Exact - Extract the tagged instance
Other extraction commands may be shown to allow extraction of the previous version of the package.

image:$image$/Image3.png

== Daemon Status
The 'Build Daemon Status' page has been modified to:
>* Allow filtering of Disabled Daemons
>* Enhanced 'Last Change Delta': 
>>* If the time since the daemon was last seen as active is greater the an hour then the delta will be shown as the time that the daemons was last active.
>>* If the time is greater than a day, then the date of the last activity is shown.
>>* Disables daemons do not show up in red

image:$image$/Image2.png

@@@@@@@@@@@@@@@@9/12/2012 6:11:12 PM : 10.240.2.79@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

==Summary of Changes
[[TOC]]
== Release Notes
The Release Manager Release notes are no longer in the VIX Wiki. Release Notes are now served by the Release Manager itself.

Some of the Release Notes from the old Wiki have been migrated, but not all.

== Subversion Path and Tag
The definition of the package source has been modified for a Subversion based package. The code is referenced via two values:

1. Source Path
{br}This is the Subversion path to the development branch of the package. The first element will be a symbolic repository reference.
{br}The last element will be the packages development branch - which may be the trunk.

2. Tag
{br}This is the a named directory within the packages 'tags' directory. It may be pegged.
{br}If the Tag is a simple number, then it will be treated as a peg of the Source Path.

image:$image$/Image1.png

== Subversion Extraction Commands
Release Manager will show Subversion specific extraction commands. The commands shown will depend on the state of the package.

If the package has been released, then Release Manager will show a single extraction command. This command will reproduce the package source in a workable workspace.

If the package has not yet been released, then Release Manager will show a number of different extraction commands. The use must select one command that will suit the intended use of the workspace. The commands allow for:
 * Default - suits most requirements.
 * Tag - Trace Tag back to development branch
 * Tip - Tip of the development branch
 * Work - Default
 * Exact - Extract the tagged instance
Other extraction commands may be shown to allow extraction of the previous version of the package.

image:$image$/Image3.png

== Daemon Status
The 'Build Daemon Status' page has been modified to:
>* Allow filtering of Disabled Daemons
>* Enhanced 'Last Change Delta': 
>>* If the time since the daemon was last seen as active is greater the an hour then the delta will be shown as the time that the daemons was last active.
>>* If the time is greater than a day, then the date of the last activity is shown.
>>* Disables daemons do not show up in red

image:$image$/Image2.png

@@@@@@@@@@@@@@@@9/12/2012 5:50:32 PM : 10.240.2.79@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

==Summary of Changes
[[TOC]]
== Subversion Path and Tag
The definition of the package source has been modified for a Subversion based package. The code is referenced via two values:

1. Source Path
{br}This is the Subversion path to the development branch of the package. The first element will be a symbolic repository reference.
{br}The last element will be the packages development branch - which may be the trunk.

2. Tag
{br}This is the a named directory within the packages 'tags' directory. It may be pegged.
{br}If the Tag is a simple number, then it will be treated as a peg of the Source Path.

image:$image$/Image1.png

== Subversion Extraction Commands
Release Manager will show Subversion specific extraction commands. The commands shown will depend on the state of the package.

If the package has been released, then Release Manager will show a single extraction command. This command will reproduce the package source in a workable workspace.

If the package has not yet been released, then Release Manager will show a number of different extraction commands. The use must select one command that will suit the intended use of the workspace. The commands allow for:
 * Default - suits most requirements.
 * Tag - Trace Tag back to development branch
 * Tip - Tip of the development branch
 * Work - Default
 * Exact - Extract the tagged instance
Other extraction commands may be shown to allow extraction of the previous version of the package.

image:$image$/Image3.png

== Daemon Status
The 'Build Daemon Status' page has been modified to:
>* Allow filtering of Disabled Daemons
>* Enhanced 'Last Change Delta': 
>>* If the time since the daemon was last seen as active is greater the an hour then the delta will be shown as the time that the daemons was last active.
>>* If the time is greater than a day, then the date of the last activity is shown.
>>* Disables daemons do not show up in red

image:$image$/Image2.png

@@@@@@@@@@@@@@@@9/12/2012 5:48:35 PM : 10.240.2.79@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

==Summary of Changes
==TOC Summary of Changes
== Subversion Path and Tag
The definition of the package source has been modified for a Subversion based package. The code is referenced via two values:

1. Source Path
{br}This is the Subversion path to the development branch of the package. The first element will be a symbolic repository reference.
{br}The last element will be the packages development branch - which may be the trunk.

2. Tag
{br}This is the a named directory within the packages 'tags' directory. It may be pegged.
{br}If the Tag is a simple number, then it will be treated as a peg of the Source Path.

image:$image$/Image1.png

== Subversion Extraction Commands
Release Manager will show Subversion specific extraction commands. The commands shown will depend on the state of the package.

If the package has been released, then Release Manager will show a single extraction command. This command will reproduce the package source in a workable workspace.

If the package has not yet been released, then Release Manager will show a number of different extraction commands. The use must select one command that will suit the intended use of the workspace. The commands allow for:
 * Default - suits most requirements.
 * Tag - Trace Tag back to development branch
 * Tip - Tip of the development branch
 * Work - Default
 * Exact - Extract the tagged instance
Other extraction commands may be shown to allow extraction of the previous version of the package.

image:$image$/Image3.png

== Daemon Status
The 'Build Daemon Status' page has been modified to:
>* Allow filtering of Disabled Daemons
>* Enhanced 'Last Change Delta': 
>>* If the time since the daemon was last seen as active is greater the an hour then the delta will be shown as the time that the daemons was last active.
>>* If the time is greater than a day, then the date of the last activity is shown.
>>* Disables daemons do not show up in red

image:$image$/Image2.png

@@@@@@@@@@@@@@@@9/12/2012 5:46:45 PM : 10.240.2.79@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

==TOC Summary of Changes
== Subversion Path and Tag
The definition of the package source has been modified for a Subversion based package. The code is referenced via two values:

1. Source Path
{br}This is the Subversion path to the development branch of the package. The first element will be a symbolic repository reference.
{br}The last element will be the packages development branch - which may be the trunk.

2. Tag
{br}This is the a named directory within the packages 'tags' directory. It may be pegged.
{br}If the Tag is a simple number, then it will be treated as a peg of the Source Path.

image:$image$/Image1.png

== Subversion Extraction Commands
Release Manager will show Subversion specific extraction commands. The commands shown will depend on the state of the package.

If the package has been released, then Release Manager will show a single extraction command. This command will reproduce the package source in a workable workspace.

If the package has not yet been released, then Release Manager will show a number of different extraction commands. The use must select one command that will suit the intended use of the workspace. The commands allow for:
 * Default - suits most requirements.
 * Tag - Trace Tag back to development branch
 * Tip - Tip of the development branch
 * Work - Default
 * Exact - Extract the tagged instance
Other extraction commands may be shown to allow extraction of the previous version of the package.

image:$image$/Image3.png

== Daemon Status
The 'Build Daemon Status' page has been modified to:
>* Allow filtering of Disabled Daemons
>* Enhanced 'Last Change Delta': 
>>* If the time since the daemon was last seen as active is greater the an hour then the delta will be shown as the time that the daemons was last active.
>>* If the time is greater than a day, then the date of the last activity is shown.
>>* Disables daemons do not show up in red

image:$image$/Image2.png

@@@@@@@@@@@@@@@@9/12/2012 5:39:19 PM : 10.240.2.79@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

[[TOC]]
== Subversion Path and Tag
The definition of the package source has been modified for a Subversion based package. The code is referenced via two values:

1. Source Path
{br}This is the Subversion path to the development branch of the package. The first element will be a symbolic repository reference.
{br}The last element will be the packages development branch - which may be the trunk.

2. Tag
{br}This is the a named directory within the packages 'tags' directory. It may be pegged.
{br}If the Tag is a simple number, then it will be treated as a peg of the Source Path.

image:$image$/Image1.png

== Subversion Extraction Commands
Release Manager will show Subversion specific extraction commands. The commands shown will depend on the state of the package.

If the package has been released, then Release Manager will show a single extraction command. This command will reproduce the package source in a workable workspace.

If the package has not yet been released, then Release Manager will show a number of different extraction commands. The use must select one command that will suit the intended use of the workspace. The commands allow for:
 * Default - suits most requirements.
 * Tag - Trace Tag back to development branch
 * Tip - Tip of the development branch
 * Work - Default
 * Exact - Extract the tagged instance
Other extraction commands may be shown to allow extraction of the previous version of the package.

image:$image$/Image3.png

== Daemon Status
The 'Build Daemon Status' page has been modified to:
>* Allow filtering of Disabled Daemons
>* Enhanced 'Last Change Delta': 
>>* If the time since the daemon was last seen as active is greater the an hour then the delta will be shown as the time that the daemons was last active.
>>* If the time is greater than a day, then the date of the last activity is shown.
>>* Disables daemons do not show up in red

image:$image$/Image2.png

@@@@@@@@@@@@@@@@9/12/2012 4:26:12 PM : 10.240.2.79@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

== Summary of Changes
 *Subversion Path and Tag
 *Subversion Extraction Commands
 *Daemon Status
== Subversion Path and Tag
The definition of the package source has been modified for a Subversion based package. The code is referenced via two values:

1. Source Path
{br}This is the Subversion path to the development branch of the package. The first element will be a symbolic repository reference.
{br}The last element will be the packages development branch - which may be the trunk.

2. Tag
{br}This is the a named directory within the packages 'tags' directory. It may be pegged.
{br}If the Tag is a simple number, then it will be treated as a peg of the Source Path.

image:$image$/Image1.png

== Subversion Extraction Commands
Release Manager will show Subversion specific extraction commands. The commands shown will depend on the state of the package.

If the package has been released, then Release Manager will show a single extraction command. This command will reproduce the package source in a workable workspace.

If the package has not yet been released, then Release Manager will show a number of different extraction commands. The use must select one command that will suit the intended use of the workspace. The commands allow for:
 * Default - suits most requirements.
 * Tag - Trace Tag back to development branch
 * Tip - Tip of the development branch
 * Work - Default
 * Exact - Extract the tagged instance
Other extraction commands may be shown to allow extraction of the previous version of the package.

image:$image$/Image3.png

== Daemon Status
The 'Build Daemon Status' page has been modified to:
>* Allow filtering of Disabled Daemons
>* Enhanced 'Las


PageData:
==Summary of Changes
[[TOC]]
== Corrected a minor issue with the "Release Notes" tab
An Oracle database error occurred when the "Release Notes" tab was being accessed outside of the Release Manager "Release page".
e.g When accessed from a Release Manager package search or from Deployment Manager


PageData:
==Summary of Changes
[[TOC]]
== Enhancements to Daemon Status Information
The "Daemon Status Information" form now has the ability to disable a build daemon. Also, a new set of control icons have been introduced to enhance the control and status of build daemons.
This is illustrated in the following picture.

image:$image$/daem_stat.JPG

==  Enhancement to JIRA Issues Importation
To better support the importing of JIRA issues into release notes, the "Project" form, opened from the "Admin" menu, now provides a way to enter a JIRA project key for each project.
This is illustrated in the following pictures.

image:$image$/jira_key.JPG

image:$image$/jira_key_edt.JPG

This feature facilitates importation of JIRA issues from the 'Import JIRA Issues', form.  When this form is opened from the "Release Notes" tab, a list of issues for the configured JIRA project key can be seen.  A JIRA project key filter is also available for additional filtering.
This is shown in the following picture.

image:$image$/jira_imp.JPG


==  Minor correction to the 'Import JIRA Issues' form 
This form has been fixed so that alert boxes are no longer displayed when the user clicks the "Previous" or "Next" page links.


==  Minor correction to the package rejection functionality 
The Release Manager system no longer calls the, make_writable, Unix script whenever a release has been rejected.


==  Added Package Re-locking Capability
The "Release Notes" tab now provides the capability for an admin user to unlock and re-lock a released package.  This is done by clicking on the "Status" field in the "Release Notes" tab.  Once clicked a confirmation window is displayed.

e.g

image:$image$/relock.JPG

PrevPageData:
@@@@@@@@@@@@@@@@9/13/2012 8:36:25 AM : 10.240.2.79@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

==Summary of Changes
[[TOC]]
== Enhancements to Daemon Status Information
The "Daemon Status Information" form now has the ability to disable a build daemon. Also, a new set of control icons have been introduced to enhance the control and status of build daemons.
This is illustrated in the following picture.

[daem_stat.JPG]

==  Enhancement to JIRA Issues Importation
To better support the importing of JIRA issues into release notes, the "Project" form, opened from the "Admin" menu, now provides a way to enter a JIRA project key for each project.
This is illustrated in the following pictures.

[jira_key.JPG]

[jira_key_edt.JPG]

This feature facilitates importation of JIRA issues from the 'Import JIRA Issues', form.  When this form is opened from the "Release Notes" tab, a list of issues for the configured JIRA project key can be seen.  A JIRA project key filter is also available for additional filtering.
This is shown in the following picture.

[jira_imp.JPG]


==  Minor correction to the 'Import JIRA Issues' form 
This form has been fixed so that alert boxes are no longer displayed when the user clicks the "Previous" or "Next" page links.


==  Minor correction to the package rejection functionality 
The Release Manager system no longer calls the, make_writable, Unix script whenever a release has been rejected.


==  Added Package Re-locking Capability
The "Release Notes" tab now provides the capability for an admin user to unlock and re-lock a released package.  This is done by clicking on the "Status" field in the "Release Notes" tab.  Once clicked a confirmation window is displayed.

e.g

[relock.JPG]


@@@@@@@@@@@@@@@@9/13/2012 8:35:53 AM : 10.240.2.79@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

== Enhancements to Daemon Status Information
The "Daemon Status Information" form now has the ability to disable a build daemon. Also, a new set of control icons have been introduced to enhance the control and status of build daemons.
This is illustrated in the following picture.

[daem_stat.JPG]

==  Enhancement to JIRA Issues Importation
To better support the importing of JIRA issues into release notes, the "Project" form, opened from the "Admin" menu, now provides a way to enter a JIRA project key for each project.
This is illustrated in the following pictures.

[jira_key.JPG]

[jira_key_edt.JPG]

This feature facilitates importation of JIRA issues from the 'Import JIRA Issues', form.  When this form is opened from the "Release Notes" tab, a list of issues for the configured JIRA project key can be seen.  A JIRA project key filter is also available for additional filtering.
This is shown in the following picture.

[jira_imp.JPG]


==  Minor correction to the 'Import JIRA Issues' form 
This form has been fixed so that alert boxes are no longer displayed when the user clicks the "Previous" or "Next" page links.


==  Minor correction to the package rejection functionality 
The Release Manager system no longer calls the, make_writable, Unix script whenever a release has been rejected.


==  Added Package Re-locking Capability
The "Release Notes" tab now provides the capability for an admin user to unlock and re-lock a released package.  This is done by clicking on the "Status" field in the "Release Notes" tab.  Once clicked a confirmation window is displayed.

e.g

[relock.JPG]


PageData:
==Summary of Changes
[[TOC]]
== Complete make_release_changed notifications (DEVI-66152)
The Release Manager system now calls a Unix script whenever the contents of a release have been changed.
This will allow packages to be quickly transferred to other sites.
This script is called when the:
 * User manually adds a package
 * User manually deletes a package from the release
 * User releases a package.
 * User bulk releases pending merged packages.
 * User releases a pending merged package.
 * User bulk releases pending manual build package.
 * Build Daemon builds and releases a new version of a package
 * Build Daemon rebuilds an existing package

== Patching a COTS package (DEVI-56057)
A new auto version of a COTS package can now be created if the package has a patch-build version number embedded in the version string. ie: The Package''''''Version.0000.cots is seen to have a patch-build version number.

When the "New Version" form is open, the option to create an auto build is disabled if the package is a COTS package and it doesn't have a patch-build version number.
This is illustrated in the following picture

image:$image$/newvercotsman.JPG

Also the Major and Minor version options are disabled if the package is a COTS package, it has a patch-build version number and auto build is selected.
This is illustrated in the following picture

image:$image$/newvercotsauto.JPG


== Release Manager enhancements to simplify build process (DEVI-046963)
The "Package Information" section of the "Release Notes" tab has been enhanced.
The contents of the "Show Details..." section of the Release Package page has been moved into the "Package Information" section and arranged as shown in the following picture.

image:$image$/packageinform.JPG

==  Build Daemon Configuration - needs to be made foolproof (DEVI-46806)
The Build Daemon Configuration now has enforced association between daemon build machine and gbe_machtype.
With the previous system it was too simple for users to misconfigure them as they were configured from free-text.
The "ADMINISTER BUILD CONFIGURATION" form now allows the specification of daemon machine hosts from a list, instead of free-text entry.

image:$image$/daemonadd.JPG

The build machine hosts are configured from a new form selected from the admin menu as shown below.

image:$image$/adminmenu.JPG
image:$image$/buildmach.JPG

The GBE machtype is associated to a build machine in this new form from a list.

image:$image$/buildmachadd.JPG

The build machine "Display Name" is a more user friendly name and is displayed to the screen instead of the hostname through out Release Manager.

== Multiple Version Control System Support in Release Manager (DEVI-051107)
The Multiple Version Control System Support of Release Manager has been enhanced to display the new JATS vcs commands and tags within the "Package information" section of the "Release Notes" tab.

The following changes were made to the "Package information" section of the "Release Notes" tab:
 * The JATS extraction commands now use the vcsrelease command and Vcs''''''Tag
 * The Previous Version now displays the version and previous Vcs''''''Tag
 * The Previous Significant Version now displays the previous version and the previous significant Vcs''''''Tag
 * The Previous Label has been removed as it is CC specific
 * The Previous Significant Label has been removed as it is CC specific
This is illustrated in the following picture.

image:$image$/jatscmd.JPG

== IMPORT dependencies operation does not handle comments (DEVI-054254)
The "Import" operation of the package "Dependencies" tab has been fixed to parse and import JATS formated text with comments.

== RM not to create descpkg files in daemon built releases (DEVI-058169)
The Release Manager was fixed as follows:
 * The file, "descpkg" is no longer created.
 * The package directory on is no longer created.

== Fix/Extend Release''''''Manager to dpkg_archive interface (DEVI-064287)
The Release Manager dpkg_archive interface was fixed as follows:
 * The unix script make_pkgfolder is no longer called.
 * The unix script make_writable, is called once when the release notes are generated.
 * The unix command to create the "doc" folder is created once when the release notes are generated.

== New Package label for Subversion package is incorrect (DEVI-065096)
When a new Subversion package version is added a default package source path string is created.
The default Subversion package source path string is created by appending the WIP label to the package subversion project branches directory.
e.g
image:$image$/svnlabel.JPG

PrevPageData:
@@@@@@@@@@@@@@@@9/13/2012 8:45:10 AM : 10.240.2.79@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

==Summary of Changes
[[TOC]]
== Complete make_release_changed notifications (DEVI-66152)
The Release Manager system now calls a Unix script whenever the contents of a release have been changed.
This will allow packages to be quickly transferred to other sites.
This script is called when the:
 * User manually adds a package
 * User manually deletes a package from the release
 * User releases a package.
 * User bulk releases pending merged packages.
 * User releases a pending merged package.
 * User bulk releases pending manual build package.
 * Build Daemon builds and releases a new version of a package
 * Build Daemon rebuilds an existing package

== Patching a COTS package (DEVI-56057)
A new auto version of a COTS package can now be created if the package has a patch-build version number embedded in the version string. ie: The PackageVersion.0000.cots is seen to have a patch-build version number.

When the "New Version" form is open, the option to create an auto build is disabled if the package is a COTS package and it doesn't have a patch-build version number.
This is illustrated in the following picture

image:$image$/newvercotsman.JPG

Also the Major and Minor version options are disabled if the package is a COTS package, it has a patch-build version number and auto build is selected.
This is illustrated in the following picture

image:$image$/newvercotsauto.JPG


== Release Manager enhancements to simplify build process (DEVI-046963)
The "Package Information" section of the "Release Notes" tab has been enhanced.
The contents of the "Show Details..." section of the Release Package page has been moved into the "Package Information" section and arranged as shown in the following picture.

image:$image$/packageinform.JPG

==  Build Daemon Configuration - needs to be made foolproof (DEVI-46806)
The Build Daemon Configuration now has enforced association between daemon build machine and gbe_machtype.
With the previous system it was too simple for users to misconfigure them as they were configured from free-text.
The "ADMINISTER BUILD CONFIGURATION" form now allows the specification of daemon machine hosts from a list, instead of free-text entry.

image:$image$/daemonadd.JPG

The build machine hosts are configured from a new form selected from the admin menu as shown below.

image:$image$/adminmenu.JPG
image:$image$/buildmach.JPG

The GBE machtype is associated to a build machine in this new form from a list.

image:$image$/buildmachadd.JPG

The build machine "Display Name" is a more user friendly name and is displayed to the screen instead of the hostname through out Release Manager.

== Multiple Version Control System Support in Release Manager (DEVI-051107)
The Multiple Version Control System Support of Release Manager has been enhanced to display the new JATS vcs commands and tags within the "Package information" section of the "Release Notes" tab.

The following changes were made to the "Package information" section of the "Release Notes" tab:
* The JATS extraction commands now use the vcsrelease command and VcsTag
* The Previous Version now displays the version and previous VcsTag
* The Previous Significant Version now displays the previous version and the previous significant VcsTag
* The Previous Label has been removed as it is CC specific
* The Previous Significant Label has been removed as it is CC specific
This is illustrated in the following picture.

image:$image$/jatscmd.JPG

== IMPORT dependencies operation does not handle comments (DEVI-054254)
The "Import" operation of the package "Dependencies" tab has been fixed to parse and import JATS formated text with comments.

== RM not to create descpkg files in daemon built releases (DEVI-058169)
The Release Manager was fixed as follows:
* The file, "descpkg" is no longer created.
* The package directory on is no longer created.

== Fix/Extend Release''''''Manager to dpkg_archive interface (DEVI-064287)
The Release Manager dpkg_archive interface was fixed as follows:
* The unix script make_pkgfolder is no longer called.
* The unix script make_writable, is called once when the release notes are generated.
* The unix command to create the "doc" folder is created once when the release notes are generated.

== New Package label for Subversion package is incorrect (DEVI-065096)
When a new SubVersion package version is added a default package source path string is created.
The default subversion package source path string is created by appending the WIP label to the package subversion project branches directory.
e.g
image:$image$/svnlabel.JPG


PageData:
==Summary of Changes
[[TOC]]
== Listing JIRA issues for the City Of Cape Town Project (DEVI-065910)
City Of Cape Town Project issues from the JIRA system are now listed when "Import JIRA Issues" is selected from the Release Note page.  Previously only JIRA issues for Stockholm and San Francisco projects were listed.


PageData:
==Summary of Changes
[[TOC]]
== New Release DEVI Status Report (DEVI-061992)
A new report has been created to help with the formation of release notes given to integration & test teams. It provides a summary of issues against package versions in the release. If the report is generated at the correct time in the release lifecycle, it can be of use in conveying to others what the updated release contains in terms of fixed issues, integration notes, database patches, etc.

This new report is located under the Release Status group of reports.
The report is named Release DEVI Status.
The report has been designed to work with data in the Release Manager database, and the ClearQuest DEVIM database (NOTE: no JIRA, and no other ClearQuest databases).
The report can be printed and most of the report data can be sent to a user via email in the form of a CSV file.

Reports are accessed via the menu near the top of the Release Manager page layout. Select the report menu which takes you to the report group page. Select the report group which then displays the list of available reports in that group. Finally, select the specific report type you require.
== Minor Changes (most of these were rolled out prior to this release as website patches)
 * New package version extensions (mcl, dev, bkk)
 * Corrected code to use latest ClearQuest schema names
 * ClearQuest issue details popup form may now show parent/child DEVI references if applicable (DEVIM only)


PageData:
==Summary of Changes
[[TOC]]
== Post Release Unit Testing and Code Reviews (DEVI-56100)
To better support those teams who may need to record testing and code review results for a package after it has been released, the rules controlling the editing of the relevant sections in the release notes page have been modified.

 * Developers can now add new unit tests to a released package.
 **All test types except Autobuild UTF may be added.
 * Developers can now delete unit tests from a released pacakge.
 ** Only unit tests that have not been "accepted" can be deleted.
 ** It will not be possible to delete an Autobuild UTF test from a released package
 * Developers can now edit/update Code Review details in a released package.
 * Developers can now add/edit/delete Code Review URLs in a released package.

== Move WIP From One Release To Another (DEVI-56237)
A new action is now available for use with a WIP version, that allows the WIP to be moved from the current release, to another release. This is a convenience function that has been found necessary on occassion and avoids the necessity to accomplish the same in a less direct or less intuitive way.

To access this functionality, a new button has been added and is shown circled in red below:

image:$image$/movewip.bmp

The button is only visible when a WIP package version is being viewed.
Selecting the button will open a new form allowing the user to select a project and subsequently a release as the new home for the WIP. 

Closed/Archived mode releases will not be shown in this form.

Once the database manipulation has been done, the browser will refresh on the page for the WIP in the destination release.

Permissions are not checked during this operation. If a user moves the WIP to a release in a project where they have no permissions to work, then they may be limited in what they can do with the WIP in the destination release. 

Before moving the WIP, the user must ensure that no daemon instructions are pending for it. Failure to do this will result in an error message reminding the user of this necessity.

== Release Type Filtering in Project's List View (DEVI-52896)
When viewing a project's releases in List View mode, users can now select from a filter, which release types they want to display.

By default, should a user do nothing with the filter, the list will display Open, Restricted, and CCB Mode releases only. This is exactly as per previous Release Manager versions. 

By using the filter, a user can turn on the display of Closed mode releases, or turn off the display of one of the other release types. Any combination is possible within the set, comprising Open, Restricted, CCB, Closed, or Archive.

image:$image$/listview.bmp

If users wish to create a bookmarked view of their project with particular filter settings in place they can do so by adding &show_filter=<x>[,<x>[,<x>]] to the query string, where <x> is one of the following:
 * 'N' (Open mode release)
 * 'A' (Archive mode release)
 * 'C' (CCB mode release)
 * 'R' (Restricted mode release)
 * 'Y' (Closed mode release)
For example
 http://erg:8002/ManagerSuite/Release_Manager/rtree.asp?proj_id=202&show_filter='C'
 http://erg:8002/ManagerSuite/Release_Manager/rtree.asp?proj_id=202&show_filter='C','N'
 http://erg:8002/ManagerSuite/Release_Manager/rtree.asp?proj_id=202&show_filter='C','N','R'
 http://erg:8002/ManagerSuite/Release_Manager/rtree.asp?proj_id=202&show_filter='C','N','R','Y'
 etc.

The filter setting is saved in a cookie, and so once it is set, repeating it in the URL query string when returning to the list view page is not necessary. However, users should now remember that they may have modified the filter lest they mistakenly think a release is missing when in fact it is just filtered.

== ClearCase Support Profile Branch Cloning (DEVI-56650)
When a new release is made based upon an existing source release, the ClearCase support profile branch of the source release is now copied to the new release. This saves having to type in the branch name manually when editing the new release.

This change is in fact a database patch but is being attributed as part of the work package for the release of this new version of the release manager website.

== Release Info Viewing (DEVI-56763)
Users who do not have permissions to edit the release information, may now view it using the same button that users with higher permissions use to edit it. See the following picture, paying particular attention to the areas circled in red.

image:$image$/rtree.bmp

Select a single release by ticking the relevant checkbox and then select the Edit button. The Release Info Editing form will be opened. If permissions for editing are not available, the form re-configures itself into a viewing form only. No field may be altered, but the current values of the fields can at least be read. 

== Downloading Build Failure Logs in FireFox (DEVI-55596)
A link to and reminder of this information has been placed on the build status form as highlighted below:

image:$image$/buildstatus.bmp

== Release Manager Front Page Control Focus (DEVI-55325)
When the Release Manager front page is initially loaded into a browser, the focus is now given initially to the Username control. Thus, a user may immediately type their user name to login.

== Cloning Branched Releases To Another Project (DEVI-55480)
Prior to this new release manager version, if a release is a branch of another release, that is, it has a parent release as seen when viewing the project in a tree view, and a user chooses such a release as the basis for another (new) release in a different project, the new release is created but is not visible in the destination project, even in the tree view.

This is because the new release has a parent release that is not in the destination project, but only in the source project. 

In this new version of release manager, when such a clone is performed, the parent release reference is removed from the new release so that it effectively becomes a non-branched release in the destination project, and will therefore be viewable. 

This change is in fact a database patch but is being attributed as part of the work package for the release of this new version of the release manager website.

PrevPageData:
@@@@@@@@@@@@@@@@9/13/2012 8:59:03 AM : 10.240.2.79@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

==Summary of Changes
[[TOC]]
== Post Release Unit Testing and Code Reviews (DEVI-56100)
To better support those teams who may need to record testing and code review results for a package after it has been released, the rules controlling the editing of the relevant sections in the release notes page have been modified.

 * Developers can now add new unit tests to a released package.
 **All test types except Autobuild UTF may be added.
 * Developers can now delete unit tests from a released pacakge.
 ** Only unit tests that have not been "accepted" can be deleted.
 ** It will not be possible to delete an Autobuild UTF test from a released package
 * Developers can now edit/update Code Review details in a released package.
 * Developers can now add/edit/delete Code Review URLs in a released package.

== Move WIP From One Release To Another (DEVI-56237)
A new action is now available for use with a WIP version, that allows the WIP to be moved from the current release, to another release. This is a convenience function that has been found necessary on occassion and avoids the necessity to accomplish the same in a less direct or less intuitive way.

To access this functionality, a new button has been added and is shown circled in red below:

image:$image$/movewip.bmp

The button is only visible when a WIP package version is being viewed.
Selecting the button will open a new form allowing the user to select a project and subsequently a release as the new home for the WIP. 

Closed/Archived mode releases will not be shown in this form.

Once the database manipulation has been done, the browser will refresh on the page for the WIP in the destination release.

Permissions are not checked during this operation. If a user moves the WIP to a release in a project where they have no permissions to work, then they may be limited in what they can do with the WIP in the destination release. 

Before moving the WIP, the user must ensure that no daemon instructions are pending for it. Failure to do this will result in an error message reminding the user of this necessity.

== Release Type Filtering in Project's List View (DEVI-52896)
When viewing a project's releases in List View mode, users can now select from a filter, which release types they want to display.

By default, should a user do nothing with the filter, the list will display Open, Restricted, and CCB Mode releases only. This is exactly as per previous Release Manager versions. 

By using the filter, a user can turn on the display of Closed mode releases, or turn off the display of one of the other release types. Any combination is possible within the set, comprising Open, Restricted, CCB, Closed, or Archive.

image:$image$/listview.bmp

If users wish to create a bookmarked view of their project with particular filter settings in place they can do so by adding &show_filter=<x>[,<x>[,<x>]] to the query string, where <x> is one of the following:
 * 'N' (Open mode release)
 * 'A' (Archive mode release)
 * 'C' (CCB mode release)
 * 'R' (Restricted mode release)
 * 'Y' (Closed mode release)
For example
 http://erg:8002/ManagerSuite/Release_Manager/rtree.asp?proj_id=202&show_filter='C'
 http://erg:8002/ManagerSuite/Release_Manager/rtree.asp?proj_id=202&show_filter='C','N'
 http://erg:8002/ManagerSuite/Release_Manager/rtree.asp?proj_id=202&show_filter='C','N','R'
 http://erg:8002/ManagerSuite/Release_Manager/rtree.asp?proj_id=202&show_filter='C','N','R','Y'
 etc.

The filter setting is saved in a cookie, and so once it is set, repeating it in the URL query string when returning to the list view page is not necessary. However, users should now remember that they may have modified the filter lest they mistakenly think a release is missing when in fact it is just filtered.

== ClearCase Support Profile Branch Cloning (DEVI-56650)
When a new release is made based upon an existing source release, the ClearCase support profile branch of the source release is now copied to the new release. This saves having to type in the branch name manually when editing the new release.

This change is in fact a database patch but is being attributed as part of the work package for the release of this new version of the release manager website.

== Release Info Viewing (DEVI-56763)
Users who do not have permissions to edit the release information, may now view it using the same button that users with higher permissions use to edit it. See the following picture, paying particular attention to the areas circled in red.

image:$image$/rtree.bmp

Select a single release by ticking the relevant checkbox and then select the Edit button. The Release Info Editing form will be opened. If permissions for editing are not available, the form re-configures itself into a viewing form only. No field may be altered, but the current values of the fields can at least be read. 

== Downloading Build Failure Logs in FireFox (DEVI-55596)
image:$image$/Click here for instructions on how to download Build Failure logs using the Firefox web browser|DownloadingBuildFailureLogsInForefox

A link to and reminder of this information has been placed on the build status form as highlighted below:

image:$image$/buildstatus.bmp

== Release Manager Front Page Control Focus (DEVI-55325)
When the Release Manager front page is initially loaded into a browser, the focus is now given initially to the Username control. Thus, a user may immediately type their user name to login.

== Cloning Branched Releases To Another Project (DEVI-55480)
Prior to this new release manager version, if a release is a branch of another release, that is, it has a parent release as seen when viewing the project in a tree view, and a user chooses such a release as the basis for another (new) release in a different project, the new release is created but is not visible in the destination project, even in the tree view.

This is because the new release has a parent release that is not in the destination project, but only in the source project. 

In this new version of release manager, when such a clone is performed, the parent release reference is removed from the new release so that it effectively becomes a non-branched release in the destination project, and will therefore be viewable. 

This change is in fact a database patch but is being attributed as part of the work package for the release of this new version of the release manager website.


PageData:
==Summary of Changes
[[TOC]]
== Clearquest VT5DM and VTSUP issue importing fixed
A long standing bug was exposed recently due to a tangential change. 
The bug manifested itself as the inability to import issues from the VT5DM and VTSUP clearquest databases, into the release notes of a package version.
The bug resulted from the failure to add additional cases to a function that retrieved issue numbers, those additional cases being one for each database. When the VT5DM and VTSUP databases were added (a long time ago) the cases should have been added, but this was overlooked for some reason.
Thus, the bug lay dormant until the tangential change that occurred that modified the error handling in release manager code related to database updates. This has now been fixed, with the necessary stored procedures being added to the relevant clearquest databases, and the extra cases added to the applicable release manager function.

== Other Minor Changes
 * Added ability to update dependencies once a WIP fails to build and enters the "excluded from build" state, and is then subsequently rejected back to pending.
 * Made the ripple properties form tolerant of missing PV_ID parameter.
 * Single quotes are now escaped in the "Reason For Version" edit fields. Previously, putting any text containing single quotes into these edit fields would cause an Oracle SQL error.
 * GBE_BUILDFILTER displayed on Build Configuration form is now wrapped text so that the form's width is not adversley affected in releases with very long build filter lists.


PageData:
==Summary of Changes
[[TOC]]
== Build Daemon Safeguards Added
The following safeguards have been added:
 * Prevent deletion of WIP when a "Test Build" daemon instruction exists for it.
 * Prevent a WIP being "made pending" when a "Test Build" daemon instruction exists for it.
 * Prevent deletion of a release when it has a build daemon configuration.
 * Prevent deletion of a release when one or more build daemon instructions exist for it.
== Other Changes
 * Added 'ncc' extension for the NSW Club Card project.
 * Made Add/Edit/Delete Daemon Instruction permissions sensitive to the instruction type.
 * Updated JIRA database connection string to align with changes done by ERGIT.


PageData:
==Summary of Changes
[[TOC]]
Besides some minor bug-fixes, this version of release manager incorporates the following changes that end-users will or may be affected by:

== Advisory Ripple
The ripple properties form now contains an additional control - one intended to set/clear the advisory ripple setting of the package version.

When a package version in a release is marked with advisory ripple, introducing a newer version of it into that release does not cause all higher level packages that depend upon it (directly or indirectly) to be rippled.

The effect of this is similar to the "ignore warnings" feature, but where that is not able to be used in a daemon enabled release, this is. However, due to the likelyhood of abuse only certain users will be able to set the advisory ripple setting. As a user, if you feel you can justify a particular package being given the advisory ripple attribute, please contact the Technology Group (David Purdie/Martin Hunt/Vy Nguyen/Gordon Huddy) who will assess your justification and apply the attribute if it is agreeable.

When a package version is given the advisory ripple attribute, the following package state icon will be displayed with the package version on the left-hand side of the release manager display when viewing a specific release: image:$image$/i_advisory_ripple.gif

== Bulk Release
Bulk Release functionality has been updated to remove a source of problem for the build system. If the bulk release contains multiple WIPS for the same package then they will be excluded from the bulk release process and the user will be told that they need to release such items individually.

This forces the WIPS for the same package to be submitted to the build system in a deterministic (and user defined) order since each will have a different date/time of submission. Previously when bulk releasing, all of those WIPS would have the same date/time of submission because the submission would happen very quickly on the web server even for multiple items. The release manager database records the date/times to 1 second resolution only. The build tool would not then be able to tell the multiple WIPS apart based on date/time.

== Build Configuration
All users can now view the build configuration information for a release. If users have sufficient permissions they may also edit the information. Previously, users without edit permissions could not even view the information, which was felt not to be very helpful.

== New Version Form
When creating a new version of a package, users will be presented with an improved "new version" form.
 * The choice between Auto and Manual is now referred to as a choice between automatic and manual version number assignment, rather than a choice between Auto and Manual build types. Underneath the hood, nothing has changed though, it is just a subtle shift in terminology. This was done because it is often the case that new versions that have a manually assigned version number may still be built by the build daemons (as long as they have good meta-data such as build std/env, label, etc). In fact, one goal is to reach a point where everything (no exceptions) is buildable by a build daemon and to get users to stop building things themselves in what may be difficult to reproduce ways, relying upon environments outside of the official build machines.
 * When users select Auto or Manual, the form now re-loads and all other controls on the form are re-initialised. Hence, selecting Auto or Manual should be the first choice a user makes before entering any other data into the form.
 * The form now allows users to enter a reason for the new version. This form control may be left blank or filled in with a reason. Users can still edit the reason later on via the release notes page.
 * Having selected an Auto assigned version number, users will get an opportunity to select the change type (major/minor/patch). Users can still edit the change type later on via the release notes page, but allowing them to set it on the new version form may save them from having to do so.
 * Having selected a Manually assigned version number, users will be able to see a drop down list of all existing version numbers for the package. This is to be used as reference information. The user will be able to see what version numbers exist and therefore choose a new one that does not exist.


PageData:
==Summary of Changes
[[TOC]]
== New Daemon Instruction - Test Build
Users can now command  a test build of a WIP using the Daemon Instruction feature introduced in [v3.31.0000=3.31.0000.cr]

When viewing a wip a new "Test Build" button will be visible that can be used to initiate a test build of the package version on the build machines.

Pressing the button will open the "add daemon instruction" form pre-populated with all the necessary details, which can be submitted immediately to add the test build instruction to the daemon instruction list within the release manager database.

The build daemon will eventually pick up the instruction and run with it, and will send an email message to the user who created the instruction once it has completed its work. This email message will inform the user of success or failure of the test build. 

Please remember that a build daemon wakes up to do work periodically, and if you submit an instruction near the start of the idle period, you will have to wait for the entire period to elapse before the instruction may get acted upon. Remember also that there will be occasions when you may have to wait even longer. For example, during scheduled downtime, during a period of "indefinite pause", or perhaps when the daemon is busy building another package (and some packages take a long time to build - eg. crypto, daf_br, etc).

At present, a test build does not run unit tests. This may be altered at some point in the future. 

Note that having added a test build daemon instruction, you should avoid deleting or otherwise changing the package version within the release. Please ensure that the package version has a label and build standard/environment before creating a test build instruction for it.

PrevPageData:
@@@@@@@@@@@@@@@@9/13/2012 9:17:54 AM : 10.240.2.79@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

== New Daemon Instruction - Test Build
Users can now command  a test build of a WIP using the Daemon Instruction feature introduced in [v3.31.0000=3.31.0000.cr]

When viewing a wip a new "Test Build" button will be visible that can be used to initiate a test build of the package version on the build machines.

Pressing the button will open the "add daemon instruction" form pre-populated with all the necessary details, which can be submitted immediately to add the test build instruction to the daemon instruction list within the release manager database.

The build daemon will eventually pick up the instruction and run with it, and will send an email message to the user who created the instruction once it has completed its work. This email message will inform the user of success or failure of the test build. 

Please remember that a build daemon wakes up to do work periodically, and if you submit an instruction near the start of the idle period, you will have to wait for the entire period to elapse before the instruction may get acted upon. Remember also that there will be occasions when you may have to wait even longer. For example, during scheduled downtime, during a period of "indefinite pause", or perhaps when the daemon is busy building another package (and some packages take a long time to build - eg. crypto, daf_br, etc).

At present, a test build does not run unit tests. This may be altered at some point in the future. 

Note that having added a test build daemon instruction, you should avoid deleting or otherwise changing the package version within the release. Please ensure that the package version has a label and build standard/environment before creating a test build instruction for it.


@@@@@@@@@@@@@@@@9/13/2012 9:14:39 AM : 10.240.2.79@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

== New Daemon Instruction - Test Build
Users can now command  a test build of a WIP using the Daemon Instruction feature introduced in [v3.31.0000|ReleaseManagerRelNotes_3.31.0000.cr]

When viewing a wip a new "Test Build" button will be visible that can be used to initiate a test build of the package version on the build machines.

Pressing the button will open the "add daemon instruction" form pre-populated with all the necessary details, which can be submitted immediately to add the test build instruction to the daemon instruction list within the release manager database.

The build daemon will eventually pick up the instruction and run with it, and will send an email message to the user who created the instruction once it has completed its work. This email message will inform the user of success or failure of the test build. 

Please remember that a build daemon wakes up to do work periodically, and if you submit an instruction near the start of the idle period, you will have to wait for the entire period to elapse before the instruction may get acted upon. Remember also that there will be occasions when you may have to wait even longer. For example, during scheduled downtime, during a period of "indefinite pause", or perhaps when the daemon is busy building another package (and some packages take a long time to build - eg. crypto, daf_br, etc).

At present, a test build does not run unit tests. This may be altered at some point in the future. 

Note that having added a test build daemon instruction, you should avoid deleting or otherwise changing the package version within the release. Please ensure that the package version has a label and build standard/environment before creating a test build instruction for it.


PageData:
==Summary of Changes
[[TOC]]
== Build Daemon Status Page
A new build daemon status page has been created that allows one to see the overall status of all build daemons at once.

This page can be opened from a new Status menu in the top-right part of the release manager pages, nestled between the existing Reports and Admin menu items.

image:$image$/Build_Daemon_Status_Menu.bmp

The page will initially open with no filtering enabled, which means you will see all daemons, for all projects, for all releases that have daemon configurations.

The page may be auto-refreshed at a minimum rate of once every 10 seconds, although obviously, if a user were to sit there pressing F5 in the browser, a higher rate can be achieved. To turn on auto-refresh, configure a desired time period and check the relevant checkbox.


image:$image$/Turn_On_Page_Refresh.bmp

The display may configured to show daemons for all projects, or a subset of them, simply be checking and un-checking the relevant project checkboxes on the left hand side of the table. 

The tables project column title has some associated buttons to check "All" and check "None" to allow a user to rapidly get to the project filtering they require (e.g. Use the "None" button, and then select one specific project checkbox to view just that one project).

image:$image$/Build_Daemon_Status_Project_Selection.bmp

Further filtering is provided in some controls above the table. 
 *Active Builds
 **These are daemons that are currently advertising a package ID in the underlying database table used as the source data for this display.
 *Problem Daemon Sets
 **These are daemon sets that might be in trouble, for example a build taking too long, etc. It is not a certain indication of such but just a prompt for an expert to go and have a look themselves to verify things are still working OK.
Check the checkboxes you desire and then turn filtering on via the radio button. 


Here is an explanation of the data shown in the table:

image:$image$/Build_Daemon_Status_Description.bmp

== Build Daemon Instructions
A new capability has been added to Release Manager to allow a user to submit commands to a build daemon outside of the regular new version-make pending-make release method. Initially, only one new command has been provided, that being "Ripple Build Package", but later on, more commands will be added that will act either upon a release as a whole, or on a specific package or package version.

This new capability will not be fully functional until the Buildtool is updated to act upon the instructions.  Currently, you can add instructions but they do not result in any daemon activity. When the Buildtool is updated, it will be announced and this wiki page updated (to remove this paragraph).

A status page has been created to show all configured build daemon instructions. This is accessible from the new Status menu to be seen in the top-right side of the release manager pages.


image:$image$/Daemon_Inst_Status_Menu.bmp

 The status page shows a list of all currently configured build daemon instructions. They can be edited and deleted as long as they are not currently being processed by a build daemon. Permission's do come into play here as well, for example you cannot add, edit or delete an instruction for a CCB/Restricted mode release if you do not have the relevant permission. 

image:$image$/Daemon_Inst_Status_Page.bmp

Build daemon instructions can be created with a scheduled time either now, or in the future (for delayed commands). It is envisaged that some commands may be periodically repeatable but the only instruction so far supported is not allowed to be. The scheduled time is used just as a threshold and users should not expect perfect timing when it comes to daemon activity triggered by these. The daemons have their own periodic processing cycle, and (for example) building some packages takes a long time so will delay execution of any daemon instructions in the list for the same release. The color display of the scheduled time column data gives a visual indication of whether the time is past (red/green) or future (black). The green color is used to indicate instructions that have yet to be acted upon. The color becomes red once the time is 10 minutes or more in the past. Should no instructions appear to be acted upon, users should check the "Build Daemon Status" page (see first item on this page) to determine what the dameon(s) are doing (if anything). They may be busy doing other things and will only get round to processing daemon instructions once they are finished.

No harm will result from creating a build daemon instruction with a scheduled time in the past, however beware that instructions older than 5 days will be deleted automatically the next time the daemon instruction status page refreshes.

Build daemon instructions may be added via this status page or via action buttons or menus on various other release manager pages.

When viewing a specific package version in a specific release, a new action button will be evident which looks like a set of waves or ripples. Hovering the mouse over this button you should see the help text "Request the Build Daemon to ripple this package version". Pressing the button brings up the same form as would have been seen had one chosen to add a daemon instruction via the daemon instruction status page. However, this time the form will be pre-loaded with the project, release, and package version being displayed at the time. All one has to do is submit the form to have the instruction added.

image:$image$/Daemon_Inst_Ripple_Build_Action_Button.bmp

There is also an "Add Daemon Instruction" menu item on the Release menu to the top-right of the release manager display, seen when viewing pages in a particular release. Once again, the same form is opened pre-loaded with the project and release currently being displayed.


image:$image$/Daemon_Inst_Add_For_Release_Menu.bmp

Note, that some build daemon instructions may not be valid. The Release Manager forms do not prevent these from being configured. For example it might not be valid to request a ripple build of some COTS packages in a release. You will find out later if the action was successful or not probably from a build-failure message from the build daemon itself.

The Build Status page for a release has been modified to summarize any build daemon instructions for the release.

PrevPageData:
@@@@@@@@@@@@@@@@9/13/2012 9:41:14 AM : 10.240.2.79@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

== Build Daemon Status Page
A new build daemon status page has been created that allows one to see the overall status of all build daemons at once.

This page can be opened from a new Status menu in the top-right part of the release manager pages, nestled between the existing Reports and Admin menu items.

image:$image$/Build_Daemon_Status_Menu.bmp

The page will initially open with no filtering enabled, which means you will see all daemons, for all projects, for all releases that have daemon configurations.

The page may be auto-refreshed at a minimum rate of once every 10 seconds, although obviously, if a user were to sit there pressing F5 in the browser, a higher rate can be achieved. To turn on auto-refresh, configure a desired time period and check the relevant checkbox.


image:$image$/Turn_On_Page_Refresh.bmp

The display may configured to show daemons for all projects, or a subset of them, simply be checking and un-checking the relevant project checkboxes on the left hand side of the table. 

The tables project column title has some associated buttons to check "All" and check "None" to allow a user to rapidly get to the project filtering they require (e.g. Use the "None" button, and then select one specific project checkbox to view just that one project).

image:$image$/Build_Daemon_Status_Project_Selection.bmp

Further filtering is provided in some controls above the table. 
 *Active Builds
 **These are daemons that are currently advertising a package ID in the underlying database table used as the source data for this display.
 *Problem Daemon Sets
 **These are daemon sets that might be in trouble, for example a build taking too long, etc. It is not a certain indication of such but just a prompt for an expert to go and have a look themselves to verify things are still working OK.
Check the checkboxes you desire and then turn filtering on via the radio button. 


Here is an explanation of the data shown in the table:

image:$image$/Build_Daemon_Status_Description.bmp

== Build Daemon Instructions
A new capability has been added to Release Manager to allow a user to submit commands to a build daemon outside of the regular new version-make pending-make release method. Initially, only one new command has been provided, that being "Ripple Build Package", but later on, more commands will be added that will act either upon a release as a whole, or on a specific package or package version.

This new capability will not be fully functional until the Buildtool is updated to act upon the instructions.  Currently, you can add instructions but they do not result in any daemon activity. When the Buildtool is updated, it will be announced and this wiki page updated (to remove this paragraph).

A status page has been created to show all configured build daemon instructions. This is accessible from the new Status menu to be seen in the top-right side of the release manager pages.


image:$image$/Daemon_Inst_Status_Menu.bmp

 The status page shows a list of all currently configured build daemon instructions. They can be edited and deleted as long as they are not currently being processed by a build daemon. Permission's do come into play here as well, for example you cannot add, edit or delete an instruction for a CCB/Restricted mode release if you do not have the relevant permission. 

image:$image$/Daemon_Inst_Status_Page.bmp

Build daemon instructions can be created with a scheduled time either now, or in the future (for delayed commands). It is envisaged that some commands may be periodically repeatable but the only instruction so far supported is not allowed to be. The scheduled time is used just as a threshold and users should not expect perfect timing when it comes to daemon activity triggered by these. The daemons have their own periodic processing cycle, and (for example) building some packages takes a long time so will delay execution of any daemon instructions in the list for the same release. The color display of the scheduled time column data gives a visual indication of whether the time is past (red/green) or future (black). The green color is used to indicate instructions that have yet to be acted upon. The color becomes red once the time is 10 minutes or more in the past. Should no instructions appear to be acted upon, users should check the "Build Daemon Status" page (see first item on this page) to determine what the dameon(s) are doing (if anything). They may be busy doing other things and will only get round to processing daemon instructions once they are finished.

No harm will result from creating a build daemon instruction with a scheduled time in the past, however beware that instructions older than 5 days will be deleted automatically the next time the daemon instruction status page refreshes.

Build daemon instructions may be added via this status page or via action buttons or menus on various other release manager pages.

When viewing a specific package version in a specific release, a new action button will be evident which looks like a set of waves or ripples. Hovering the mouse over this button you should see the help text "Request the Build Daemon to ripple this package version". Pressing the button brings up the same form as would have been seen had one chosen to add a daemon instruction via the daemon instruction status page. However, this time the form will be pre-loaded with the project, release, and package version being displayed at the time. All one has to do is submit the form to have the instruction added.

image:$image$/Daemon_Inst_Ripple_Build_Action_Button.bmp

There is also an "Add Daemon Instruction" menu item on the Release menu to the top-right of the release manager display, seen when viewing pages in a particular release. Once again, the same form is opened pre-loaded with the project and release currently being displayed.


image:$image$/Daemon_Inst_Add_For_Release_Menu.bmp

Note, that some build daemon instructions may not be valid. The Release Manager forms do not prevent these from being configured. For example it might not be valid to request a ripple build of some COTS packages in a release. You will find out later if the action was successful or not probably from a build-failure message from the build daemon itself.

The Build Status page for a release has been modified to summarize any build daemon instructions for the release. 


@@@@@@@@@@@@@@@@9/13/2012 9:40:14 AM : 10.240.2.79@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

Go back to [Release Manager|ReleaseManager] page
\\
\\
\\
[{TableOfContents}]
\\
!!!Build Daemon Status Page
A new build daemon status page has been created that allows one to see the overall status of all build daemons at once.
\\
\\This page can be opened from a new Status menu in the top-right part of the release manager pages, nestled between the existing Reports and Admin menu items.
\\
[Build_Daemon_Status_Menu.bmp]
\\
\\The page will initially open with no filtering enabled, which means you will see all daemons, for all projects, for all releases that have daemon configurations.
\\
\\The page may be auto-refreshed at a minimum rate of once every 10 seconds, although obviously, if a user were to sit there pressing F5 in the browser, a higher rate can be achieved. To turn on auto-refresh, configure a desired time period and check the relevant checkbox.
\\
\\
[Turn_On_Page_Refresh.bmp]
\\
\\The display may configured to show daemons for all projects, or a subset of them, simply be checking and un-checking the relevant project checkboxes on the left hand side of the table. 
\\
\\The tables project column title has some associated buttons to check "All" and check "None" to allow a user to rapidly get to the project filtering they require (e.g. Use the "None" button, and then select one specific project checkbox to view just that one project).
\\
[Build_Daemon_Status_Project_Selection.bmp]
\\
\\Further filtering is provided in some controls above the table. 
*Active Builds
**These are daemons that are currently advertising a package ID in the underlying database table used as the source data for this display.
*Problem Daemon Sets
**These are daemon sets that might be in trouble, for example a build taking too long, etc. It is not a certain indication of such but just a prompt for an expert to go and have a look themselves to verify things are still working OK.
Check the checkboxes you desire and then turn filtering on via the radio button. 
\\
\\
Here is an explanation of the data shown in the table:
\\
[Build_Daemon_Status_Description.bmp]

!!!Build Daemon Instructions
A new capability has been added to Release Manager to allow a user to submit commands to a build daemon outside of the regular new version-make pending-make release method. Initially, only one new command has been provided, that being "Ripple Build Package", but later on, more commands will be added that will act either upon a release as a whole, or on a specific package or package version.
\\
\\This new capability will not be fully functional until the Buildtool is updated to act upon the instructions.  Currently, you can add instructions but they do not result in any daemon activity. When the Buildtool is updated, it will be announced and this wiki page updated (to remove this paragraph).
\\
\\A status page has been created to show all configured build daemon instructions. This is accessible from the new Status menu to be seen in the top-right side of the release manager pages.
\\
\\
[Daemon_Inst_Status_Menu.bmp]
\\
\\ The status page shows a list of all currently configured build daemon instructions. They can be edited and deleted as long as they are not currently being processed by a build daemon. Permission's do come into play here as well, for example you cannot add, edit or delete an instruction for a CCB/Restricted mode release if you do not have the relevant permission. 
\\
[Daemon_Inst_Status_Page.bmp]
\\
\\Build daemon instructions can be created with a scheduled time either now, or in the future (for delayed commands). It is envisaged that some commands may be periodically repeatable but the only instruction so far supported is not allowed to be. The scheduled time is used just as a threshold and users should not expect perfect timing when it comes to daemon activity triggered by these. The daemons have their own periodic processing cycle, and (for example) building some packages takes a long time so will delay execution of any daemon instructions in the list for the same release. The color display of the scheduled time column data gives a visual indication of whether the time is past (red/green) or future (black). The green color is used to indicate instructions that have yet to be acted upon. The color becomes red once the time is 10 minutes or more in the past. Should no instructions appear to be acted upon, users should check the "Build Daemon Status" page (see first item on this page) to determine what the dameon(s) are doing (if anything). They may be busy doing other things and will only get round to processing daemon instructions once they are finished.
\\
\\No harm will result from creating a build daemon instruction with a scheduled time in the past, however beware that instructions older than 5 days will be deleted automatically the next time the daemon instruction status page refreshes.
\\
\\Build daemon instructions may be added via this status page or via action buttons or menus on various other release manager pages.
\\
\\When viewing a specific package version in a specific release, a new action button will be evident which looks like a set of waves or ripples. Hovering the mouse over this button you should see the help text "Request the Build Daemon to ripple this package version". Pressing the button brings up the same form as would have been seen had one chosen to add a daemon instruction via the daemon instruction status page. However, this time the form will be pre-loaded with the project, release, and package version being displayed at the time. All one has to do is submit the form to have the instruction added.
\\
[Daemon_Inst_Ripple_Build_Action_Button.bmp]
\\
\\There is also an "Add Daemon Instruction" menu item on the Release menu to the top-right of the release manager display, seen when viewing pages in a particular release. Once again, the same form is opened pre-loaded with the project and release currently being displayed.
\\
\\
[Daemon_Inst_Add_For_Release_Menu.bmp]
\\
\\Note, that some build daemon instructions may not be valid. The Release Manager forms do not prevent these from being configured. For example it might not be valid to request a ripple build of some COTS packages in a release. You will find out later if the action was successful or not probably from a build-failure message from the build daemon itself.
\\
\\The Build Status page for a release has been modified to summarize any build daemon instructions for the release. 


@@@@@@@@@@@@@@@@9/13/2012 9:29:51 AM : 10.240.2.79@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

image:$image$/Turn_On_Page_Refresh.bmp

@@@@@@@@@@@@@@@@9/13/2012 9:25:24 AM : 10.240.2.79@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

== Build Daemon Status Page
A new build daemon status page has been created that allows one to see the overall status of all build daemons at once.

This page can be opened from a new Status menu in the top-right part of the release manager pages, nestled between the existing Reports and Admin menu items.

image:$image$/Build_Daemon_Status_Menu.bmp

The page will initially open with no filtering enabled, which means you will see all daemons, for all projects, for all releases that have daemon configurations.

The page may be auto-refreshed at a minimum rate of once every 10 seconds, although obviously, if a user were to sit there pressing F5 in the browser, a higher rate can be achieved. To turn on auto-refresh, configure a desired time period and check the relevant checkbox.

image:$image$/Turn_On_Page_Refresh.bmp



@@@@@@@@@@@@@@@@9/13/2012 9:24:34 AM : 10.240.2.79@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

aaabbb


PageData:
==Summary of Changes
[[TOC]]
== Remove "Ignore Warnings" Capability on Build Daemon Enabled Releases
The ability to "ignore warnings" on build dependencies, has been removed in build daemon enabled releases. This is because in such releases, the capability is irrelevent.

Releases with no build daemon configuration retain the "Ignore Warnings" capability.

== Add Patches Form
Various bugs in the Add Patches form have been fixed.

In the past, patch numbering was not enforced and hence it was possible that a patch could be released where the initial pXXX part of the number remained (when in fact the user should have replaced XXX with a 3 digit number). Later on, when making a newer patch, the historical patch whose number was pXXX could cause an ASP server process to enter an infinite loop when the AutoFill button was used. This has been corrected.

Additionally, form submission now results in patch number validation to ensure the format of the patch number is correct. An error message will be displayed if the validation fails, giving the user a chance to correct the problem before attempting form submission once again.

The AutoFill button will now be hidden if there are no items in the Dependency Patches list. This makes sure users can only see and use the standard Submit button in such cases.

If there are items in the Dependency Patches list but the user has not selected any checkbox in the Auto column, selecting the AutoFill button will result in an error message rather than proceeding with the form submission (which used to fail in such circumstances).

With respect to the Dependency Patches list (if any), note that the checkboxes on the left of the form (Manual column) are utilised when form submission occurs through the Submit button, and checkboxes on the right (Auto column) are utilised when form submission occurs through the AutoFill button.

PrevPageData:
@@@@@@@@@@@@@@@@9/13/2012 9:53:14 AM : 10.240.2.79@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

== Remove "Ignore Warnings" Capability on Build Daemon Enabled Releases
The ability to "ignore warnings" on build dependencies, has been removed in build daemon enabled releases. This is because in such releases, the capability is irrelevent.

Releases with no build daemon configuration retain the "Ignore Warnings" capability.

== Add Patches Form
Various bugs in the Add Patches form have been fixed.

In the past, patch numbering was not enforced and hence it was possible that a patch could be released where the initial pXXX part of the number remained (when in fact the user should have replaced XXX with a 3 digit number). Later on, when making a newer patch, the historical patch whose number was pXXX could cause an ASP server process to enter an infinite loop when the AutoFill button was used. This has been corrected.

Additionally, form submission now results in patch number validation to ensure the format of the patch number is correct. An error message will be displayed if the validation fails, giving the user a chance to correct the problem before attempting form submission once again.

The AutoFill button will now be hidden if there are no items in the Dependency Patches list. This makes sure users can only see and use the standard Submit button in such cases.

If there are items in the Dependency Patches list but the user has not selected any checkbox in the Auto column, selecting the AutoFill button will result in an error message rather than proceeding with the form submission (which used to fail in such circumstances).

With respect to the Dependency Patches list (if any), note that the checkboxes on the left of the form (Manual column) are utilised when form submission occurs through the Submit button, and checkboxes on the right (Auto column) are utilised when form submission occurs through the AutoFill button.


PageData:
==Table of Contents
[[TOC]]
These are release notes made by Rupesh Solanki/Jeremy Tweddle prior to the handover of development to the current package owner.


== Version: 3.29.1000.cr
Release Date: 15-Aug-2008

Fixed some SQL errors leading to misleading metric displays.

DEVI-049291     Release Manager metrics display is misleading


== Version: 3.29.0000.cr   (reversioned so as to continue numbering after 3.28)
Release Date: 8-Aug-2008

Major changes: Implement BULK RELEASE, fixup Merge display to show merge candidates in pending table

DEVI-048440     Release Manager "Bulk Release" button does not work

DEVI-049594     Merge operation display needs to show merge candidates already in destination pending tab

DEVI-045275     merge manager feature should merge into pending

DEVI-050133     Use This Version functionality is not available in the new Release

DEVI-050252     Find File can fail with an Oracle automation error

DEVI-047990     Oracle Automation Error when Searching for a Pkg with 'Find a File' Selected


== Version: 0.0.1000.cr    (reversioned as a core package from a previously extensionless package)
Release Date: 28-July-2008

DEVI-034837     Additional Properties to ANT-using style Dependency Export

DEVI-043066     Prevent packages being created/changed without an extension

DEVI-044075     Should not be able to create a WIP for a COTS package

DEVI-047501     New 'Ripple Type' required: Do not ripple. Manual intervention required

DEVI-048040     ERG Logo image on release manager page comes from deployment manager web site

DEVI-048136     Release Manager clearcase structure omits the docs folder

DEVI-049230     Release Manager has incorrect ADODB connection string for document repository

DEVI-049267     Ripple Type Properties cannot be modifed on a locked package by anyone except the legend.

DEVI-049871     Problems when adding build dependencies to a WIP


== Version: 3.28.0000
Release Date: 16-July-2008

DEVI-047641     Package with build dependencies missing in a release is silently ignored by the buildtool.

== Version: 3.27.2000
Release Date: 2-July-2008

DEVI-046991     Release Manager / Build Daemon Mail interface needs to made usable

DEVI-049259     Integrity constraint error when adding view owners to view "NONE"

DEVI-049302     VBscript error in Edit Project View Details



== Version: 3.27.1000
Release Date: 25-Jun-2008

DEVI-049118     Unecessary jira and clearquest database connections and querries

== Version: 3.27.0
Release Date: 11-Jun-2008

 * show ccdiff and ccbc2 commands in release notes
 * merge manager now merges into pending table, not released table
 * daemon pause button now works under IE6
 * fixed "used by" tab problem

DEVI-045066     Release Manager to create command to simplfy Code Reviews

DEVI-045275     merge manager feature should merge into pending

DEVI-048158     Daemon Pause button does not work under IE6, may not work reliably under firefox

DEVI-048653     Release Manager Beta - Used By Tab is broken

== Version: 3.26.0
Release Date: 28-May-2008

 * Metric Collection
 * Release Manager restrictions on pasting Code Review URLs are too restrictive
 * Package Version Locking/Unlocking
 * Various Urgent Bug fixes

DEVI-033954     Automated Unit Testing Extensions for Release Manager

DEVI-046293     Release Manager Code Review URL capture is too restrictive and un-friendly from end-user perspective


== Version: 3.25.0
Release Date: 15-May-2008

 * Modified the find files section so that it can search within patches.
 * Added hints on the home page so that the user can use wildcards to find files.
 * Modified the build status page to enable excluded packages to be re-included.
 * Fixed a bug that caused runtime errors to occur when attempting to re-version a package.
 * Changed date in copyright notice.
 * Fixed a bug that caused unit test results not to be uploaded when using Firefox.

DEVI-035113     Release Manager: Cannot re-version a package under Internet Explorer

DEVI-041086     Release manager is unable to find files in patches see attachment for example

DEVI-041805     "Make Bulk Patches Official" Window Not Correctly Sized and Elements Not Correctly Placed

DEVI-043582     Gathering information on Impact/Risk to affected Products for each package release

DEVI-044186     unable to manager build daemons in release manager, specifically delete them

DEVI-044396     Release Manager should check new package names

DEVI-044469     Release Manager. Selection of Major,Minor and Patch change

== Version: 3.24.0
Release Date: 30-August-2007

 * Extended the Code Review section to include fields for URLs linking to external code review tools.
 * Fixed a bug that caused "Fixed Issues For Last Non-Ripple Build" not to be shown in the "Reason for last non-ripple build" section.

DEVI-040584     Add links in Release Manager to code reviews in external web-based code review tools

== Version: 3.23.0
Release Date: 26-July-2007

 * Added SBOM Priority functionality
 * Added Project Issues Report
 * Added support for COMING SOON build daemons
 * Added support for Java 1.6
 * Added ReleaseInfo Functionality
 * Destroying Personal WIPs.
 * Notification to the SBOM Management Team
 * Sanity Check
 * Release Difference - Union With Archive Manager
 * Added GBE_BUILDFILTER to the Release Configuration

DEVI-033923     DEVI    Release Manager : Unable to approve autobuild while release in open mode

DEVI-034530     DEVI    RM function request: SBOM version per package

DEVI-035092     DEVI    Bad version number causes SQL exception in RM

DEVI-035093     DEVI    No check for existing version number in Release Manager New Version operation

DEVI-035094     DEVI    Developers canot delete a WIP/New Version in RM

DEVI-035337     DEVI    Better Release Manager Config Specs

DEVI-036160     DEVI    maintain tab in when changing pages Release Manager

DEVI-037294     DEVI    Insertion of release info into Clearquest

== Version: 3.22.0
Release Date: 27-April-2007

Removal of Email Notification About Package Ready to be Built.

The admin section in Release Manager has now been broken down into the following to accomodate any future expansions:
 *Build Service
 **This is where all the Build Service Configuration can take place.
 *GBE Machtype
 **This is where amendments can be made in regards to the Machtype.
 *Archive
 **The archival process is now automated from the GUI. Therefore once the administrators feel comfortable they can archive the requested release to be archived and at any time they can move a release from archival to release manager.

== Version: 3.21.0
Release Date: 31-January-2007

Functionality Feature Between Release Manager and Deployment Manager

There has been a change in the application Release Manager to make the process between Release and Deployment Manager more formal.

This would not affect Projects/Releases that are not interested in using this functionality.

Currently it has been switched on for SITS LEGACY AND SITS RELEASE 1 AND 2.

Users with the role to configure/edit a release should be able to toggle on/off for their releases.

If it's switched on, it would affect the availability of products in Deployment Manager that could be incorporated into an SBOM.


== Version: 3.20.0
Release Date: 21-December-2006

=== Release Autobuildable Report Released
This would help in getting the correct statistical results for DEVI-033954 (Dashboard Functionality).

=== Archived History Faeture Added (DEVI-033926)
I am concerned that Archiving a release in Release Manager means that historical information concerning packages will be lost.

That is, the archive process will remove all versions of a package that are no longer referenced by a non-archived release.

This means that the history of packages are lost - we will only be able to view the release notes of a few spot releases.

We will then not be able to see the release notes of other releases that may have contained the major changes and are therefore losing valuable information.

From Martin Hunt 30/11/2006: Rupesh suggested viewing package history as per normal,
and viewing archived packaged history if required. MM is happy with this approach. It should keep us all happy.

I understand the intent here is that there are two History buttons on the pacakge page, "History" and "Archived History".

Once a RM release is moved to Archive Mode, the archive process will move the RM release and all packages no longer referenced by a non-Archived release into the Archive RM database. RM will then show all non-archived packages from the "History" button and all archived packages from the "Archived History" button. No release notes will be deleted by this process and all will be accessible using either button. However, all artifiacts associated with the archived packages will be archived from dpkg_archive and will no longer be accessible except from tape.

=== Bug Fix - Detected by Steve Kinsman
Importing of Package Dependencies in a Release.

=== Bug Fix - Detected by Steve Kinsman
Used By Feature

== Version: 3.19.0
Release Date: 07-December-2006

Moving forward with the autobuild and having daemon builds, a number of GUI changes have been put in place for different levels of access for users:

=== Developers:
The Build Environment section under the Package Information section would have the Build Machines:
Solaris, Win32, Linux, Generic. Cannot set Generic with other options, but can set Solaris and Win32 and Linux.

NB: Solaris could map to any number of Solaris machines, depending on the project eg Solaris 8 sparc, Solaris 10 sparc, Solaris 10 x64, Solaris 11 (coming soon)
Win32 could map to any number of Win32 machines, depending on the project eg XP Server 2003, XP Pro x64 Edition, Vista (coming soon)
ditto Linux
Generic maps to all machines, depending on the project

In addition to that, there would be a section for defining ERG's Build Standards: JATS, ANT or none (only a Leader can check none on a new package, default is JATS on a new package)

Depending on the selection of the Build Standard, the Addendums available would be:
JATS Addendum: Debug, Production, Debug and Production
ANT Addendum: Java 1.4, Java 1.5

=== Project Administrators
Administrators would be able to configure the build daemons and machtypes per release.
For example, we can associate release ABC with the GBE_MACHTYPES: solaris10_x86, solaris10_sparc, win32 etc.
Each of these GBE_MACHTYPE would be associated with a hostname to identify the build machine delivering that GBE_MACHTYPE.
These daemons would then be associated with a host either in MASTER or SLAVE mode. Only onde daemon can be the master.

== Version: 3.18.0
Release Date: 13-October-2006

 *Creating From Other Release Completed - Pending Work Completed
 **Users can now create a new release from a release existing in a different project.
 *Check Release Before Closing Release - Simon Morley Request
 **This functionality would enable the user to make sure there does not reside any package versions in the Work In Progress or Pending before closing a release. He has the option to either move all or delete all.
 *Select All Patches In Bulk Release - Mel Luy Request
 **This functionality has now been added so that patches can be released in batch mode.
 *Display Text when switching Between the Tabs - Lee Rewell Request
 **The text to find in a given tab will now not disappear when the user switches between the tabs.
 *Access to Access Manager from Admin Menu
 **This has been added so that users of Access Manager can gain access into the application.
 *Added the Escrow Report
 *Added the functionality to Ignore Dependencies from the Used By Tab - Morgan Dell Request

== Version: 3.17.0
Release Date: 19-July-2006

 *Obsoleting Patches
 **You should now be able to select a patch that would make a patch obsolete
 *Make Bulk Patch Releases
 **This would enable you to release several patches in one go instead of having to do it one patch at a time. The following example displays the patches that can be selected and released when "Make Release Bulk Patches" is clicked under the patches tab in Release Manager:
 ***Reports -> Advanced Search -> Find ClearQuest Bugs/Issues Location
 **Use this section under the reports to display the package names and versions that have been associated with a given issue.
 *Depreacation State
 **Deprecated and deprecated dependency packages would now be the lowest priority compared to the other states that a package can exist in.
 *Patches Automation Process
 **An automative feature in Release Manager hsa been added for the patches section even though the existing manual process will still exist for users. I have tested with patches for Sydney but maybe other projects may be interested as well. The automative feature will do the following:
 ***User selects the auto checkboxes for dependency patches that he/she wants to include and clicks on the AutoFill button (the magic stuff button).
 ***This would then invoke the script to do the following:
 ****Create new versions of the patches with the patch versions set to be the ones displayed in bold grey (selected versions only).
 ****It will then go into dpkg_archive and look under the dependency package name and version scripts folder and read the shell script that is associated with it.
 ****The reason for this version under the release notes will then be populated with the value set to be "Schema Patch - (PATCH_ENV1)". (PATCH_ENV1 would be the value that is assigned in the shell script).
 ****The package overview will be updated with the short description text.
 ****Build environment will not be applicable as patches do not need them. (Please do let me know if I am wrong== )
 ****The default package label will then be applied.
 ****There are no unit tests done on patches therefore it would mean that section would by default be "Unit Test is not done".
 ***The automation process will therefore be saving a lot of time which currently the users spend on to make and release patches. (The manual process will still use the same old principal and click on Submit(DO NOT USE AutoFill for manual process).)
 *Interactive Unit Tests
 **These tests would now be carried over when a new version of a package is created but the only the "Summary" section would be cloned from the previous version. The rest of the test information needs to be filled up by the developers.


== Version: 3.16.0
Release Date: 19-May-2006

There are changes in Release Manager and Deployment Manager so that the generation of node spec files is automated and the business processes involved made efficient and less time-consuming. This involves the introduction of a mechanism that would enable users to add/import processes to package versions in Release Manager and to the platforms in a given node in a BOM (Bills Of Materials) in Deployment Manager. In general, the mechanism can be described in the following steps:
1. Insert processes/instances of processes in a given package version in Release Manager.
2. Import the processes/instances of processes to the platforms in a given node in Deployment Manager.
3. Generate the NodeSpecFiles from Deployment Manager to be used.


== Version: 3.15.0
Release Date:12-May-2006

 *Adding Package Interest in a given Project
 **This functionality has now been added under the member's notifications section. Users would select the project and the package that they have interest in so that they can be notified when a new version of the package is officially released/ready for autobuild in the selected project.
 *Editing Release Notes For a Package in Pending State
 **Administrators, Leaders and Managers will now have the power to edit the release notes when a package has been officially released into the pending state.
 *Clearquest Issues Filtering enabled for VTSUP and TDSE databases
 *JIRA Issues
 **All states of Jira Issues can now be imported into JIRA table under the Release Notes section.


== Version: 3.14.0
Release Date:13-Apr-2006

 *Autobuild Failure Email Requirement
 **A new feature has been added to Release Manager so as to support a functionality to notify the "base view" owners in a given project that a package existing in a view has failed the autobuild. There will be 2 categories of build failure: Failure to generate derived files; Failure to run unit tests.
 **The subject of the email will reflect whichever category applies, and will incorporate the release and package name.
 **The content of the email will be a url to the relevant build log or test log. The url will be available for a number of days.
 **Project Administrators will have access to add/remove view owners whereas the rest of the Release Manager users would have read only access.


== Version: 3.13.0
Release Date: 04-Apr-2006

 *Adding Autobuild Notifier for a Release - Administrator Users
 **The interface for editing a release has been extended to include the "Autobuild Notifications Emails" field that would make use of the functionality to notify the autobuild administrator of a release that a certain package version is ready for autobuild.
 *JIRA Issues - San Francisco and Stockholm Users Only
 **For the above mentioned projects only, there has been some modification of the issues section under the "Release Notes" in Release Manager so that they could import JIRA issues from the JIRA database into Release Manager. The issues section would later be merged into one in the next release.
 *Fixed DEVI's included in the Autobuild Notification
 **The email that gets sent to the autobuild notifier would now include FIXED DEVI's associated with the package version.

== Version: 3.12.0
Release Date: 28-Mar-2006

 *Package Deprecation Per Project Release - Administrators Only
 **Release Manager now supports the deprecation  of a package per Release. For example:
 ***I have a package crypto that I need to deprecate from a Release. I will have to indicate to the users of that package that the package will be removed in a future release and that they should migrate away from it's use by clicking on the icon indicated below.
 ***I also need to provide instructions as to how this might be done. i.e Use an alternate package.
 ***This would then flag the deprecated package as well as it's dependancy packages as shown below.
 *Bill Of Materials (BOM) Contents Report Included In Release Manager
 **Deployment Manager users can now have a quick glance of BOM contents under the Escrow link.
 *Reason For Last Non-Ripple Build
 **Support has been added to display the reason for the last non-ripple build package version. This would be shown under the Release Notes section of the Release Manager.
 **NB: This would only show up if and only if the Reason for this Version indicates it's a Ripple Build.
 *Build Environment under Package Information
 **To assist in auto-building and enable users from indicating a build environment when the "build environment not applicable" is not selected, it will now be compulsory to either choose "build environment not applicable" or select a build environment unlike before when the user could get away with this.


== Version: 3.11.0
Release Date: 13-Mar-2006

 *Support to 'roll-up' patches and obsolete them in one go
 **Under the "Patches" section in Release Manager, a new icon called "Roll-up Obsolete Patches" has been added so that Release Manager can support the ability to select all the obsoleted patches and obsolete them in one go, with the same comment applied to all the patches. ("Obsoleted by roll-up patch XXXX")
 *Export Dependencies In ClearCase Style
 **The ClearCase Style under the Export Dependencies section of the Release Manager has been revised and modified to display the package versions as per their official release.
 **NB: The rest of the styles i.e JATS Style, JANT Style, ANT-using Style would remain the same.

 *Creating New Version - in MASS REF
 **Since we could not create a new version of a core/mass package in a release with an associated MASS REF, a new button  has been added so that for such kind of packages, clicking on the button would redirect you to the associated MASS REF so as to create a new version of the particular package.


== Version: 3.10.0
Release Date: 27-Feb-2006

 *Filtering Rippled Build Packages In Merge Manager
 **Filtering rippled build packages functionality has been added in the Merge Manager section of the Release Manager. This would allow to identify changes from a software perspective.
 *Report Format Modified In Merge Manager
 **The automated report that is generated and sent when a user wants to get the difference report between two given releases has been modified so as to avoid creating a lengthy report. The new format would be as per the attachment.
 *View-Name Group Added In Merge Manager
 **The packages would now be grouped based on the view name followed by the list of packages under the view.
 *Merge Release Under a CCB Mode
 **Only Administrators would be able to merge changes into a Release that is under a CCB Mode.



== Version: 3.9.0
Release Date: 8-Feb-2006

 *Addition of new style (ANT-using) for dependency export list for Java builders.
 **This will allow Java developers to add this text directly into there xml file and make life a great deal easier for themselves.
 *Ripple Buildable
 **Under the package information section in the release notes, the field ripple buildable has been added to assist in auto-building of packages by users.
 *Patch Release
 **The following roles would be now able to "make release" a patch:
 ***Administrator
 ***DBA
 ***Leader
 *ERG Products with Patches
 **Products would now show dependency patches that have been officially released.


== Version: 3.8.1
Release Date: 3-Feb-2006

Ripple Buildable Functionality Added
The ripple buildable functionality is now in production. The following is a summary of the change:
-By default, when a new version is created the field Ripple Buildable is set to Yes.
-Only Administrators have the full privilege to change the Ripple Buildable state of a package version.


== Version: 3.8.0
Release Date: 18-Jan-2006

 *Clearcase Support Profiles Functionality
 **When a developer creates a "New Version" on a package, Release Manager will send out an
email to the developer with the specific Clearcase Support Profiles (config specs) to be used.
 **For Project Releases mentioned above, if a package version has not been "officially" released then
the Clearcase Support Profiles (config specs) can be viewed under the "Show Details" section of the Release
Notes for that particular package version.

== Version: 3.7.0
Release Date: 12-Jan-2006

 *Reports – Build History (12/01/06)
 **This report would be able to find which packages have been officially released in a given release within specified date range.


== Version: 3.6.0
Release Date: 04-Jan-2006

 *DEVI-021352
 **For projects such as Sydney and Seattle that have an associated MASS_REF release we need a mechanism to prevent users adding/modifying  a .mas or a .cr pakage to the Sydney/Seatte release. The package must be manipulated in the associated MASS_REF release.
 **I have marked this issue critical as it keeps on causing problems that are taking valuable time to resolve.
 **Suggested solution.
 ***Need per-release flag to indicate that the release has a related MASS_REF release.
 ***It would be very nice to actually configure the associated ( linked) MASS_REF set - this could be used inplace of the flag.
 ***When the flag is set then it should not be possible to add a .mas/.cr package within the release, nor should it be possible to: create a new version of a .mas/.cr package or change the version.


== Version: 3.5.0
Release Date: 22-Dec-2005

 *DEVI-021077
 **We need to be able to generate a "difference" report between two different releases.
 **The idea would be to use the "merge manager" feature to compare two releases. Then to be able to generate a difference report between the two with all the changes and DEVI's that have been fixed. You can probably ignore "ripple" builds if possible.
 *DEVI-021331
 **I have asked Rupesh to implement a new CCB mode to release manager. This will differ to restricted mode in terms of Make Release on a manually built package: basically a leader will be able to do it in restricted mode (back to the future), but not in CCB mode.


== Version: 3.4.0
Release Date: 21-Dec-2005

 *DEVI-021074:
 **I would like to roadmap the following functionality in the development of the release manager. It relates to what a role can do on a release in restricted mode (the mode used when a release is being autobuilt).
 ***Team MASS - can work on MASS_REF releases (is authorised)
 ***Team Sydney - can work on Sydney releases (is authorised)
 ***Team Seattle - etc
 ***Developer
 ****can create a new version of a package already in the release
 ****can edit the new version
 ****can Make Pending on a package being autobuilt
 ***Leader
 ****can Make Release a package being autobuilt
 ***Administrator
 ****can Make Release a package being manually built (this prevents a Leader from releasing the package without CCB approval)
 ****can add a new package to a release (without having to put the release in open mode)
 ****can remove a package from a release (without having to put the release in open mode)
 ****can put the release in open, restricted or closed mode


== Version: 2.2.0
Release Date: 01-Apr-2003

 * Fixed the gap between the tabs when browser is set to the largest font.
 * Username is now min 2 chars.
 * BUG#22 - Domain passwords can now support spaces in them.
 * Popup windows now always focus on top even if they are minimised.
 * Release now contains COTS folder containing all Release Manager preinstall requirements.
 * When whole release is made official, only non-release packages are locked and therefore, last modifier id is changed for those packages only.
 * On new version creation, "version already exists..." message is removed as it was confusing with users.
 * "Make Official" button created instead "Status:" link for clearer understanding
 * BUG#25 - Base View name is now available at package details page.
 * BUG#23 - Quick package name lookup implemented.
 * BUG#24 - Parent folder button implemented.
 * BUG#29 - ORA ERROR Invalid Row Reference in _new_version.asp is fixed (Reported by John Ng)
 * BUG#21 - Indication whether pkg is released is implemented with lock icon.
 * "Reason for release" of the package now displays HTML format so  will be translated to link.
 * Contents page now has option to view other versions available at dpkg_archive.
 * Source path and Label are now required.
 * Base view combo box now show all base views on adding a package to release.


== Version: 2.1.0
Release Date: 8-Nov-2002

Initial release of Release Manager V2 for testing

PrevPageData:
@@@@@@@@@@@@@@@@9/13/2012 3:57:30 PM : 10.240.2.79@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

These are release notes made by Rupesh Solanki/Jeremy Tweddle prior to the handover of development to the current package owner.


== Version: 3.29.1000.cr
Release Date: 15-Aug-2008

Fixed some SQL errors leading to misleading metric displays.

DEVI-049291     Release Manager metrics display is misleading


== Version: 3.29.0000.cr   (reversioned so as to continue numbering after 3.28)
Release Date: 8-Aug-2008

Major changes: Implement BULK RELEASE, fixup Merge display to show merge candidates in pending table

DEVI-048440     Release Manager "Bulk Release" button does not work

DEVI-049594     Merge operation display needs to show merge candidates already in destination pending tab

DEVI-045275     merge manager feature should merge into pending

DEVI-050133     Use This Version functionality is not available in the new Release

DEVI-050252     Find File can fail with an Oracle automation error

DEVI-047990     Oracle Automation Error when Searching for a Pkg with 'Find a File' Selected


== Version: 0.0.1000.cr    (reversioned as a core package from a previously extensionless package)
Release Date: 28-July-2008

DEVI-034837     Additional Properties to ANT-using style Dependency Export

DEVI-043066     Prevent packages being created/changed without an extension

DEVI-044075     Should not be able to create a WIP for a COTS package

DEVI-047501     New 'Ripple Type' required: Do not ripple. Manual intervention required

DEVI-048040     ERG Logo image on release manager page comes from deployment manager web site

DEVI-048136     Release Manager clearcase structure omits the docs folder

DEVI-049230     Release Manager has incorrect ADODB connection string for document repository

DEVI-049267     Ripple Type Properties cannot be modifed on a locked package by anyone except the legend.

DEVI-049871     Problems when adding build dependencies to a WIP


== Version: 3.28.0000
Release Date: 16-July-2008

DEVI-047641     Package with build dependencies missing in a release is silently ignored by the buildtool.

== Version: 3.27.2000
Release Date: 2-July-2008

DEVI-046991     Release Manager / Build Daemon Mail interface needs to made usable

DEVI-049259     Integrity constraint error when adding view owners to view "NONE"

DEVI-049302     VBscript error in Edit Project View Details



== Version: 3.27.1000
Release Date: 25-Jun-2008

DEVI-049118     Unecessary jira and clearquest database connections and querries

== Version: 3.27.0
Release Date: 11-Jun-2008

 * show ccdiff and ccbc2 commands in release notes
 * merge manager now merges into pending table, not released table
 * daemon pause button now works under IE6
 * fixed "used by" tab problem

DEVI-045066     Release Manager to create command to simplfy Code Reviews

DEVI-045275     merge manager feature should merge into pending

DEVI-048158     Daemon Pause button does not work under IE6, may not work reliably under firefox

DEVI-048653     Release Manager Beta - Used By Tab is broken

== Version: 3.26.0
Release Date: 28-May-2008

 * Metric Collection
 * Release Manager restrictions on pasting Code Review URLs are too restrictive
 * Package Version Locking/Unlocking
 * Various Urgent Bug fixes

DEVI-033954     Automated Unit Testing Extensions for Release Manager

DEVI-046293     Release Manager Code Review URL capture is too restrictive and un-friendly from end-user perspective


== Version: 3.25.0
Release Date: 15-May-2008

 * Modified the find files section so that it can search within patches.
 * Added hints on the home page so that the user can use wildcards to find files.
 * Modified the build status page to enable excluded packages to be re-included.
 * Fixed a bug that caused runtime errors to occur when attempting to re-version a package.
 * Changed date in copyright notice.
 * Fixed a bug that caused unit test results not to be uploaded when using Firefox.

DEVI-035113     Release Manager: Cannot re-version a package under Internet Explorer

DEVI-041086     Release manager is unable to find files in patches see attachment for example

DEVI-041805     "Make Bulk Patches Official" Window Not Correctly Sized and Elements Not Correctly Placed

DEVI-043582     Gathering information on Impact/Risk to affected Products for each package release

DEVI-044186     unable to manager build daemons in release manager, specifically delete them

DEVI-044396     Release Manager should check new package names

DEVI-044469     Release Manager. Selection of Major,Minor and Patch change

== Version: 3.24.0
Release Date: 30-August-2007

 * Extended the Code Review section to include fields for URLs linking to external code review tools.
 * Fixed a bug that caused "Fixed Issues For Last Non-Ripple Build" not to be shown in the "Reason for last non-ripple build" section.

DEVI-040584     Add links in Release Manager to code reviews in external web-based code review tools

== Version: 3.23.0
Release Date: 26-July-2007

 * Added SBOM Priority functionality
 * Added Project Issues Report
 * Added support for COMING SOON build daemons
 * Added support for Java 1.6
 * Added ReleaseInfo Functionality
 * Destroying Personal WIPs.
 * Notification to the SBOM Management Team
 * Sanity Check
 * Release Difference - Union With Archive Manager
 * Added GBE_BUILDFILTER to the Release Configuration

DEVI-033923     DEVI    Release Manager : Unable to approve autobuild while release in open mode

DEVI-034530     DEVI    RM function request: SBOM version per package

DEVI-035092     DEVI    Bad version number causes SQL exception in RM

DEVI-035093     DEVI    No check for existing version number in Release Manager New Version operation

DEVI-035094     DEVI    Developers canot delete a WIP/New Version in RM

DEVI-035337     DEVI    Better Release Manager Config Specs

DEVI-036160     DEVI    maintain tab in when changing pages Release Manager

DEVI-037294     DEVI    Insertion of release info into Clearquest

== Version: 3.22.0
Release Date: 27-April-2007

Removal of Email Notification About Package Ready to be Built.

The admin section in Release Manager has now been broken down into the following to accomodate any future expansions:
 *Build Service
 **This is where all the Build Service Configuration can take place.
 *GBE Machtype
 **This is where amendments can be made in regards to the Machtype.
 *Archive
 **The archival process is now automated from the GUI. Therefore once the administrators feel comfortable they can archive the requested release to be archived and at any time they can move a release from archival to release manager.

== Version: 3.21.0
Release Date: 31-January-2007

Functionality Feature Between Release Manager and Deployment Manager

There has been a change in the application Release Manager to make the process between Release and Deployment Manager more formal.

This would not affect Projects/Releases that are not interested in using this functionality.

Currently it has been switched on for SITS LEGACY AND SITS RELEASE 1 AND 2.

Users with the role to configure/edit a release should be able to toggle on/off for their releases.

If it's switched on, it would affect the availability of products in Deployment Manager that could be incorporated into an SBOM.


== Version: 3.20.0
Release Date: 21-December-2006

=== Release Autobuildable Report Released
This would help in getting the correct statistical results for DEVI-033954 (Dashboard Functionality).

=== Archived History Faeture Added (DEVI-033926)
I am concerned that Archiving a release in Release Manager means that historical information concerning packages will be lost.

That is, the archive process will remove all versions of a package that are no longer referenced by a non-archived release.

This means that the history of packages are lost - we will only be able to view the release notes of a few spot releases.

We will then not be able to see the release notes of other releases that may have contained the major changes and are therefore losing valuable information.

From Martin Hunt 30/11/2006: Rupesh suggested viewing package history as per normal,
and viewing archived packaged history if required. MM is happy with this approach. It should keep us all happy.

I understand the intent here is that there are two History buttons on the pacakge page, "History" and "Archived History".

Once a RM release is moved to Archive Mode, the archive process will move the RM release and all packages no longer referenced by a non-Archived release into the Archive RM database. RM will then show all non-archived packages from the "History" button and all archived packages from the "Archived History" button. No release notes will be deleted by this process and all will be accessible using either button. However, all artifiacts associated with the archived packages will be archived from dpkg_archive and will no longer be accessible except from tape.

=== Bug Fix - Detected by Steve Kinsman
Importing of Package Dependencies in a Release.

=== Bug Fix - Detected by Steve Kinsman
Used By Feature

== Version: 3.19.0
Release Date: 07-December-2006

Moving forward with the autobuild and having daemon builds, a number of GUI changes have been put in place for different levels of access for users:

=== Developers:
The Build Environment section under the Package Information section would have the Build Machines:
Solaris, Win32, Linux, Generic. Cannot set Generic with other options, but can set Solaris and Win32 and Linux.

NB: Solaris could map to any number of Solaris machines, depending on the project eg Solaris 8 sparc, Solaris 10 sparc, Solaris 10 x64, Solaris 11 (coming soon)
Win32 could map to any number of Win32 machines, depending on the project eg XP Server 2003, XP Pro x64 Edition, Vista (coming soon)
ditto Linux
Generic maps to all machines, depending on the project

In addition to that, there would be a section for defining ERG's Build Standards: JATS, ANT or none (only a Leader can check none on a new package, default is JATS on a new package)

Depending on the selection of the Build Standard, the Addendums available would be:
JATS Addendum: Debug, Production, Debug and Production
ANT Addendum: Java 1.4, Java 1.5

=== Project Administrators
Administrators would be able to configure the build daemons and machtypes per release.
For example, we can associate release ABC with the GBE_MACHTYPES: solaris10_x86, solaris10_sparc, win32 etc.
Each of these GBE_MACHTYPE would be associated with a hostname to identify the build machine delivering that GBE_MACHTYPE.
These daemons would then be associated with a host either in MASTER or SLAVE mode. Only onde daemon can be the master.

== Version: 3.18.0
Release Date: 13-October-2006

 *Creating From Other Release Completed - Pending Work Completed
 **Users can now create a new release from a release existing in a different project.
 *Check Release Before Closing Release - Simon Morley Request
 **This functionality would enable the user to make sure there does not reside any package versions in the Work In Progress or Pending before closing a release. He has the option to either move all or delete all.
 *Select All Patches In Bulk Release - Mel Luy Request
 **This functionality has now been added so that patches can be released in batch mode.
 *Display Text when switching Between the Tabs - Lee Rewell Request
 **The text to find in a given tab will now not disappear when the user switches between the tabs.
 *Access to Access Manager from Admin Menu
 **This has been added so that users of Access Manager can gain access into the application.
 *Added the Escrow Report
 *Added the functionality to Ignore Dependencies from the Used By Tab - Morgan Dell Request

== Version: 3.17.0
Release Date: 19-July-2006

 *Obsoleting Patches
 **You should now be able to select a patch that would make a patch obsolete
 *Make Bulk Patch Releases
 **This would enable you to release several patches in one go instead of having to do it one patch at a time. The following example displays the patches that can be selected and released when "Make Release Bulk Patches" is clicked under the patches tab in Release Manager:
 ***Reports -> Advanced Search -> Find ClearQuest Bugs/Issues Location
 **Use this section under the reports to display the package names and versions that have been associated with a given issue.
 *Depreacation State
 **Deprecated and deprecated dependency packages would now be the lowest priority compared to the other states that a package can exist in.
 *Patches Automation Process
 **An automative feature in Release Manager hsa been added for the patches section even though the existing manual process will still exist for users. I have tested with patches for Sydney but maybe other projects may be interested as well. The automative feature will do the following:
 ***User selects the auto checkboxes for dependency patches that he/she wants to include and clicks on the AutoFill button (the magic stuff button).
 ***This would then invoke the script to do the following:
 ****Create new versions of the patches with the patch versions set to be the ones displayed in bold grey (selected versions only).
 ****It will then go into dpkg_archive and look under the dependency package name and version scripts folder and read the shell script that is associated with it.
 ****The reason for this version under the release notes will then be populated with the value set to be "Schema Patch - (PATCH_ENV1)". (PATCH_ENV1 would be the value that is assigned in the shell script).
 ****The package overview will be updated with the short description text.
 ****Build environment will not be applicable as patches do not need them. (Please do let me know if I am wrong== )
 ****The default package label will then be applied.
 ****There are no unit tests done on patches therefore it would mean that section would by default be "Unit Test is not done".
 ***The automation process will therefore be saving a lot of time which currently the users spend on to make and release patches. (The manual process will still use the same old principal and click on Submit(DO NOT USE AutoFill for manual process).)
 *Interactive Unit Tests
 **These tests would now be carried over when a new version of a package is created but the only the "Summary" section would be cloned from the previous version. The rest of the test information needs to be filled up by the developers.


== Version: 3.16.0
Release Date: 19-May-2006

There are changes in Release Manager and Deployment Manager so that the generation of node spec files is automated and


PageData:
==Summary of Changes
[[TOC]]
== Metrics
The metrics displays on the front page of release manager have been enhanced as follows:
a) One can now find the top 10 changed packages in the last week, month, or 3 months. 
b) Metric history for individual packages is now available.
c) Some erroneous metric queries and calculations have been corrected.

These new features of the metrics displays are demoed in the tutorial video found here:
[Enhanced Metrics|http://erg:8080/webdav/TechnologyGroup/manager_suite_tutorials/release_manager/MetricsDisplays/MetricsDisplays.html]

== Bulk Release
There is a new button available when viewing a project release's Pending Tab, that can be used to approve multiple checked pending versions simultaneously. The bulk release button also approves new versions for building with the build tool, or manually built versions in a restricted/CCB release. In a restricted/CCB release, only Team Leaders will be able to use this new button.

The use of the bulk release button is demoed in the tutorial video found here (also covering the new merge manager features):
[Merging And Bulk Releasing|http://erg:8080/webdav/TechnologyGroup/manager_suite_tutorials/release_manager/MergingAndBulkReleasing/MergingAndBulkReleasing.html]

== Merging
The merge manager display now shows items that have been merged to the destination release's pending tab.
Both merging and the use of the bulk release button are demoed in the tutorial video found here:
[Merging And Bulk Releasing|http://erg:8080/webdav/TechnologyGroup/manager_suite_tutorials/release_manager/MergingAndBulkReleasing/MergingAndBulkReleasing.html]

== Dependency Export
When exporting dependencies in ANT-using style, some additional properties are now created to support the operation of other tools. The new properties describe the project and release that the package was built for.

== New rules regarding package version extensions
In the past, users were free to create package versions with any extension they wished. This has led to a proliferation of silly extensions, and even the creation of versions without extensions. From now on, users will have to select an extension from a predefined set. Also, users will no longer be able to create extension-less versions. When a new extension is required, users must contact the Technology Core Team (Vy Nguyen/David Purdie/Martin Hunt/Gordon Huddy) to have the new extension approved and incorporated into the pre-programmed set.

Please Note:- The first time you create a new version for a package that has had till now, an extension-less version, you are strongly advised to make it a manual build type, and set the major/minor/patch number aspects of the version number such that it has the correct relationship to the previous major/minor/patch version aspects. This is because if you leave it to the build tool to assign the version number, it will do it starting from 0 in all three aspects (major, minor and patch) because it does not see the new version (now with an extension) as being a continuation of the old (extension-less) version.

Note also that the Version History display of Release Manager will not initially show both extension-less and extensioned versions of the same package. This is because the formation of the display uses pattern matching against the version + extension. For example, say you converted a package from extension-less to extentioned with .cr, the history display will open using a wildcard of *.cr and so the extension-less versions will not be shown. To overcome this, you can just change the wildcard to *.* on the history form. When re-submitted, the form will refresh with all versions of the package. Some improvements in the version history display form may be forthcoming in a future version of Release Manager, depending upon user feedback received.

== New rules for WIP's for COTS packages
When creating a new version of a COTS package, users must now always select "Manual" build type. This is because the build tools cannot convert a WIP number back into a COTS version number. Users will have to use "Manual" builds and choose the exact version number for the new COTS package version. If a user selects "Automated" build type for a COTS package, they will be shown an error message when submitting the New Version form.

== New rules for adding Build/Run-Time Dependencies
The process of adding build or run-time dependencies to a WIP version has been reworked such that:
a) Only packages that are already used in the release, are presented in the ADD dependency form
b) Users are not able to select an arbitrary version of a dependent package. Release Manager will always use the version of the package that is currently in the release.

PrevPageData:
@@@@@@@@@@@@@@@@9/13/2012 4:00:39 PM : 10.240.2.79@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@


== Metrics
The metrics displays on the front page of release manager have been enhanced as follows:
a) One can now find the top 10 changed packages in the last week, month, or 3 months. 
b) Metric history for individual packages is now available.
c) Some erroneous metric queries and calculations have been corrected.

These new features of the metrics displays are demoed in the tutorial video found here:
[Enhanced Metrics|http://erg:8080/webdav/TechnologyGroup/manager_suite_tutorials/release_manager/MetricsDisplays/MetricsDisplays.html]

== Bulk Release
There is a new button available when viewing a project release's Pending Tab, that can be used to approve multiple checked pending versions simultaneously. The bulk release button also approves new versions for building with the build tool, or manually built versions in a restricted/CCB release. In a restricted/CCB release, only Team Leaders will be able to use this new button.

The use of the bulk release button is demoed in the tutorial video found here (also covering the new merge manager features):
[Merging And Bulk Releasing|http://erg:8080/webdav/TechnologyGroup/manager_suite_tutorials/release_manager/MergingAndBulkReleasing/MergingAndBulkReleasing.html]

== Merging
The merge manager display now shows items that have been merged to the destination release's pending tab.
Both merging and the use of the bulk release button are demoed in the tutorial video found here:
[Merging And Bulk Releasing|http://erg:8080/webdav/TechnologyGroup/manager_suite_tutorials/release_manager/MergingAndBulkReleasing/MergingAndBulkReleasing.html]

== Dependency Export
When exporting dependencies in ANT-using style, some additional properties are now created to support the operation of other tools. The new properties describe the project and release that the package was built for.

== New rules regarding package version extensions
In the past, users were free to create package versions with any extension they wished. This has led to a proliferation of silly extensions, and even the creation of versions without extensions. From now on, users will have to select an extension from a predefined set. Also, users will no longer be able to create extension-less versions. When a new extension is required, users must contact the Technology Core Team (Vy Nguyen/David Purdie/Martin Hunt/Gordon Huddy) to have the new extension approved and incorporated into the pre-programmed set.

Please Note:- The first time you create a new version for a package that has had till now, an extension-less version, you are strongly advised to make it a manual build type, and set the major/minor/patch number aspects of the version number such that it has the correct relationship to the previous major/minor/patch version aspects. This is because if you leave it to the build tool to assign the version number, it will do it starting from 0 in all three aspects (major, minor and patch) because it does not see the new version (now with an extension) as being a continuation of the old (extension-less) version.

Note also that the Version History display of Release Manager will not initially show both extension-less and extensioned versions of the same package. This is because the formation of the display uses pattern matching against the version + extension. For example, say you converted a package from extension-less to extentioned with .cr, the history display will open using a wildcard of *.cr and so the extension-less versions will not be shown. To overcome this, you can just change the wildcard to *.* on the history form. When re-submitted, the form will refresh with all versions of the package. Some improvements in the version history display form may be forthcoming in a future version of Release Manager, depending upon user feedback received.

== New rules for WIP's for COTS packages
When creating a new version of a COTS package, users must now always select "Manual" build type. This is because the build tools cannot convert a WIP number back into a COTS version number. Users will have to use "Manual" builds and choose the exact version number for the new COTS package version. If a user selects "Automated" build type for a COTS package, they will be shown an error message when submitting the New Version form.


== New rules for adding Build/Run-Time Dependencies
The process of adding build or run-time dependencies to a WIP version has been reworked such that:
a) Only packages that are already used in the release, are presented in the ADD dependency form
b) Users are not able to select an arbitrary version of a dependent package. Release Manager will always use the version of the package that is currently in the release.

Go back to [Release Manager|ReleaseManager] page


PageData:
== Licencing
Release Manager can now record simple licencing associations for individual package versions.

=== Adding a licence
To do this, a licence has to be configured. 
This may be done by users who have the "ConfigureBuildService" permission. Currently, this is limited to the Administrator role. 
To add a licence, use the "Licences" option on the Admin menu.
In the current release, a licence configuration consists simply of an ID and a name. Users of Release Manager will only be aware of the name.
=== Associating a Package Version with a Licence
Once a licence has been configured, a package version can be associated with it.
This can be done by anyone. 
To associate a package version with a licence, go to the release and use the "Edit Licencing" option on the Release menu. A form will open displaying all the package versions in the release alongside checkboxes that show the current licence association. Select the licence you wish to consider via the drop down list and then check or un-check the checkboxes to associate or disassociate a package version with the licence. Click the OK button when finished. 
=== Viewing all licence associations for a release
To view which package versions have been associated with licences, go to the release and use the "View Licencing" option on the Release menu. 
A form will open displaying package versions with licencing associations. Only the package versions that have associations will be shown.
=== NOTES
NOTE that when new versions of packages are created, either manually by Release Manager users, or by the build daemon's when rippling packages, any licencing associations are automatically inherited from the predecessor versions.

NOTE that a package version can be associated with more than one licence if need be.


PageData:
== Smarter Build Daemon Ripple Rules

A new ripple type has been invented known as "Limited". This can be selected in the Ripple Type combo on the form opened when editing the ripple properties of a package version.
When "Limited" is selected, you must select values for the 4 version limit fields. These limits will inform the Build Daemon on how to change the version number when it ripple builds the package.

The "Limited" ripple type will be useful for MOS THX and WinCe modules: These get mugged and there are limits on the version numbers. 
The Mos package limits: Major 0 .. 99, Minor 0 .. 99, Patch: Not Allowed, Build: Not allowed.
The WinCE package limits: Major 0..9, Minor 0..9, Patch: 0.9, Build Not allowed. 
Currently problems are being seen in the WinCE builds where the patch number is being rippled past 9 and causing failures in consumer packages.

eg if a package is given a ripple field of Limited and has limits 0,0,0,0 the package cannot effectively be ripple built (ie requires manual intervention)

eg if a package is given a ripple field of Limited and has limits 1,0,0,1 and is at version 0.0.0.0001, the following sequence of ripple numbers will be applied...

 1.0.0.0000
 1.0.0.0001

after that, the package cannot be ripple built


PageData:
==Summary of Changes
[[TOC]]
== Indefinite Pause is not visible to user
When the build daemons are forced into indefinite pause, users can now see this via the Build Status page. A warning will be displayed, and users will not be able to control the state of individual daemons for their release until the indefinite pause is cleared. During the indefinite pause condition, individual build daemon states will be shown as "Stopped".

== Permissions for editing the Build Standard information
An annomaly in permission handling with respect to the Package Information display of the Release Notes page for a package version has been resolved. Users able to Edit the package information could not also edit the build standard information. The fix for this annomaly has now been formalised. Prior to now it was installed as a patch on the production website code, when it was first noticed by an end-user.


PageData:
==Summary of Changes
[[TOC]]
== Release of Multiple WIPS for same package
For database releases there is often a requirement to release the same package multiple times, without having to wait for the previous to complete before releasing the next. Build daemons should be able to queue multiple releases of the same package in the order they were released.  If any ripple builds are affected they should wait until the final dependant package in the queue is built.

Earlier versions of Release Manager prevented this because earlier versions of the build daemon tool could not handle this situation. However, this has now been rectified in v13.2.2000.cr of the build tool, and so now the business rules inherent in Release Manager have been changed to allow for the above requirement to be satisfied.

NOTE: As part of this change, Release Manager will no longer issue "build required" email notifications to package owners when packages are approved for auto-build. These email notifications were deemed unecessary now that we have the build daemons running to perform the builds for us.


PageData:
==Summary of Changes
[[TOC]]
== Database Interfacing Improvements
This change should not have any obvious visible effect upon the end-user of Release Manager.

The change is designed to make consistent the code in the website that performs updates upon the Release Manager database. Over the years, many people have worked on the code base and inconsistencies (and perhaps even logic errors) have crept in. A sweep across the entire code base of the tool has been performed in an attempt to tidy up this problem.

Having said this, there is always the possibility of new problems having been introduced with such a large scale change. Users should report all problems via DEVIs as usual.


PageData:
==Summary of Changes
[[TOC]]
== Multiple Version Control System (VCS) Support
== Background
The Release Manager schema and website code have been updated to provide some support for the selection of alternative version control systems. 
Some may already be aware of the potential move away from ClearCase to SubVersion. This seems ever more likely given the high costs associated with ClearCase support, and its poor performance in the area of multi-site development. 
Henceforth, when preparing new package versions, users will need to make a choice between the following version control systems:
 * Uncontrolled
 * ClearCase
 * SubVersion (*)
(*) Initially, SubVersion will not be available. It will be enabled once all of the necessary tools in the development environment have been updated and deployed. This includes the build (daemon) tool and JATS.

Evidence of the new features in Release Manager become apparent when viewing the Release Notes tab for a package version. 

The Package Information section on the page has been modified. It now displays the version control system in use for the package version. And depending upon which VCS is in use, the remaining items in the package information section will differ. For example, if a package version is Uncontrolled, no label or source path fields will be shown.

== Build Standard and Build Environments
Prior to now, users had to click a button next to the "Build Standard" text in the package information display, in order to modify the build standard. This button has now been removed. The build standard and build environments can all be modified within the form that is opended when a user chooses to edit the package information (see below).

== Modifying Package Information
The form used to edit package information has now changed in the following ways:
 * A new VCS selection combo box is shown
 ** Select Uncontrolled if your source is not in ClearCase and you intend to perform some kind of local manual build publishing artifacts directly into dpkg_archive (or if your source is in ClearCase but because you are going to do a manual build, you do not need to publicise its label or location for the build daemon tools). This choice has been made available to reflect the fact that many package versions have been created in the past that seemed to be like this. Mostly, these seem to be database patches of some kind. Needless to say, our QMS demands that source be controlled to enable reproducibility, and it should be labelled accordingly.
 ** Select ClearCase for all current controlled source. Eventually, you will see SubVersion become available in the combo box, when we are ready to start using it, although at this time we do not have a specific target date for that.
 * VCS Sensitivity
 ** The rows that follow the VCS selection combo box vary depending upon which VCS has been selected
 ** When ClearCase is selected, you will see Label and Source Path input fields.
 ** When Uncontrolled is selected, you will not see any Label or Source Path input fields.
 ** When SubVersion is selected, you will see a SubVersion Tag input field, and no Label or Source Path input fields.
 * A new Build Standard selection combo box is shown
 ** Now users can select the build standard directly on this form instead of previously having to do it in another form.

== Business Rule Changes
Some business rules are in place that users should be aware of. 
NOTE: Not all of these are implemented within the package information editing form. Some become apparent when a user attempts to make the package pending/released.
 * Auto-build package versions must __not__ have a VCS type of Uncontrolled
 * Auto-build package versions must __not__ have a build standard of NONE
 * Auto-build package versions must have at least one build environment selected
 * There is no longer any permissions restriction upon which users can select a build standard of NONE.

== Other Problems Addressed
Previously, it was impossible to select build environments Linux + Solaris + Win32 for a package version using a build standard of ANT. This has been fixed.

== Minor Report Tool Changes
The report generation tools within Release Manager have been altered such that the information for "Build Environments" (on those reports that have this) now display 
 *{build standard}, {build machine}
where {build standard} may be NONE, ANT, or JATS
and {build machine} may be Solaris, Win32, Linux, or Generic.

== About Page Changes
The About page has been altered to be automatically updated during a JATS build of Release Manager. Previously, the Release Manager developer would have to update this manually, and add some text to a change history text file that is part of the deployed file set. This often got overlooked leading to misleading information being given to the end user, or the need to patch the website post-deployment.
Now, the page is auto-configured to point to the release notes pages on the WIKI, of which this page is a part.

PrevPageData:
@@@@@@@@@@@@@@@@9/13/2012 4:13:22 PM : 10.240.2.79@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

==Summary of Changes
[[TOC]]
== Multiple Version Control System (VCS) Support
== Background
The Release Manager schema and website code have been updated to provide some support for the selection of alternative version control systems. 
Some may already be aware of the potential move away from ClearCase to SubVersion. This seems ever more likely given the high costs associated with ClearCase support, and its poor performance in the area of multi-site development. 
Henceforth, when preparing new package versions, users will need to make a choice between the following version control systems:
 * Uncontrolled
 * ClearCase
 * SubVersion (*)
(*) Initially, SubVersion will not be available. It will be enabled once all of the necessary tools in the development environment have been updated and deployed. This includes the build (daemon) tool and JATS.

Evidence of the new features in Release Manager become apparent when viewing the Release Notes tab for a package version. 

The Package Information section on the page has been modified. It now displays the version control system in use for the package version. And depending upon which VCS is in use, the remaining items in the package information section will differ. For example, if a package version is Uncontrolled, no label or source path fields will be shown.

== Build Standard and Build Environments
Prior to now, users had to click a button next to the "Build Standard" text in the package information display, in order to modify the build standard. This button has now been removed. The build standard and build environments can all be modified within the form that is opended when a user chooses to edit the package information (see below).

== Modifying Package Information
The form used to edit package information has now changed in the following ways:
 * A new VCS selection combo box is shown
 ** Select Uncontrolled if your source is not in ClearCase and you intend to perform some kind of local manual build publishing artifacts directly into dpkg_archive (or if your source is in ClearCase but because you are going to do a manual build, you do not need to publicise its label or location for the build daemon tools). This choice has been made available to reflect the fact that many package versions have been created in the past that seemed to be like this. Mostly, these seem to be database patches of some kind. Needless to say, our QMS demands that source be controlled to enable reproducibility, and it should be labelled accordingly.
 ** Select ClearCase for all current controlled source. Eventually, you will see SubVersion become available in the combo box, when we are ready to start using it, although at this time we do not have a specific target date for that.
 * VCS Sensitivity
 ** The rows that follow the VCS selection combo box vary depending upon which VCS has been selected
 ** When ClearCase is selected, you will see Label and Source Path input fields.
 ** When Uncontrolled is selected, you will not see any Label or Source Path input fields.
 ** When SubVersion is selected, you will see a SubVersion Tag input field, and no Label or Source Path input fields.
 * A new Build Standard selection combo box is shown
 ** Now users can select the build standard directly on this form instead of previously having to do it in another form.

== Business Rule Changes
Some business rules are in place that users should be aware of. 
NOTE: Not all of these are implemented within the package information editing form. Some become apparent when a user attempts to make the package pending/released.
 * Auto-build package versions must __not__ have a VCS type of Uncontrolled
 * Auto-build package versions must __not__ have a build standard of NONE
 * Auto-build package versions must have at least one build environment selected
 * There is no longer any permissions restriction upon which users can select a build standard of NONE.

== Other Problems Addressed
 * Previously, it was impossible to select build environments Linux + Solaris + Win32 for a package version using a build standard of ANT. This has been fixed.

== Minor Report Tool Changes
The report generation tools within Release Manager have been altered such that the information for "Build Environments" (on those reports that have this) now display 
 #@3C;build standard#@3E;, #@3C;build machine#@3E;
where #@3C;build standard#@3E; may be NONE, ANT, or JATS
and #@3C;build machine#@3E; may be Solaris, Win32, Linux, or Generic.

== About Page Changes
The About page has been altered to be automatically updated during a JATS build of Release Manager. Previously, the Release Manager developer would have to update this manually, and add some text to a change history text file that is part of the deployed file set. This often got overlooked leading to misleading information being given to the end user, or the need to patch the website post-deployment.
Now, the page is auto-configured to point to the release notes pages on the WIKI, of which this page is a part.


@@@@@@@@@@@@@@@@9/13/2012 4:11:25 PM : 10.240.2.79@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

==Summary of Changes
[[TOC]]
== Multiple Version Control System (VCS) Support
== Background
The Release Manager schema and website code have been updated to provide some support for the selection of alternative version control systems. 
Some may already be aware of the potential move away from ClearCase to SubVersion. This seems ever more likely given the high costs associated with ClearCase support, and its poor performance in the area of multi-site development. 
Henceforth, when preparing new package versions, users will need to make a choice between the following version control systems:
 * Uncontrolled
 * ClearCase
 * SubVersion (*)
(*) Initially, SubVersion will not be available. It will be enabled once all of the necessary tools in the development environment have been updated and deployed. This includes the build (daemon) tool and JATS.

Evidence of the new features in Release Manager become apparent when viewing the Release Notes tab for a package version. 

The Package Information section on the page has been modified. It now displays the version control system in use for the package version. And depending upon which VCS is in use, the remaining items in the package information section will differ. For example, if a package version is Uncontrolled, no label or source path fields will be shown.

== Build Standard and Build Environments
Prior to now, users had to click a button next to the "Build Standard" text in the package information display, in order to modify the build standard. This button has now been removed. The build standard and build environments can all be modified within the form that is opended when a user chooses to edit the package information (see below).

== Modifying Package Information
The form used to edit package information has now changed in the following ways:
 * A new VCS selection combo box is shown
 ** Select Uncontrolled if your source is not in ClearCase and you intend to perform some kind of local manual build publishing artifacts directly into dpkg_archive (or if your source is in ClearCase but because you are going to do a manual build, you do not need to publicise its label or location for the build daemon tools). This choice has been made available to reflect the fact that many package versions have been created in the past that seemed to be like this. Mostly, these seem to be database patches of some kind. Needless to say, our QMS demands that source be controlled to enable reproducibility, and it should be labelled accordingly.
 ** Select ClearCase for all current controlled source. Eventually, you will see SubVersion become available in the combo box, when we are ready to start using it, although at this time we do not have a specific target date for that.
 * VCS Sensitivity
 ** The rows that follow the VCS selection combo box vary depending upon which VCS has been selected
 ** When ClearCase is selected, you will see Label and Source Path input fields.
 ** When Uncontrolled is selected, you will not see any Label or Source Path input fields.
 ** When SubVersion is selected, you will see a SubVersion Tag input field, and no Label or Source Path input fields.
 * A new Build Standard selection combo box is shown
 ** Now users can select the build standard directly on this form instead of previously having to do it in another form.

== Business Rule Changes
Some business rules are in place that users should be aware of. 
NOTE: Not all of these are implemented within the package information editing form. Some become apparent when a user attempts to make the package pending/released.
 * Auto-build package versions must __not__ have a VCS type of Uncontrolled
 * Auto-build package versions must __not__ have a build standard of NONE
 * Auto-build package versions must have at least one build environment selected
 * There is no longer any permissions restriction upon which users can select a build standard of NONE.

== Other Problems Addressed
 * Previously, it was impossible to select build environments Linux + Solaris + Win32 for a package version using a build standard of ANT. This has been fixed.

== Minor Report Tool Changes
The report generation tools within Release Manager have been altered such that the information for "Build Environments" (on those reports that have this) now display 
 *#@3C;build standard>, #@3C;build machine>
where #@3C;build standard> may be NONE, ANT, or JATS
and #@3C;build machine> may be Solaris, Win32, Linux, or Generic.

== About Page Changes
The About page has been altered to be automatically updated during a JATS build of Release Manager. Previously, the Release Manager developer would have to update this manually, and add some text to a change history text file that is part of the deployed file set. This often got overlooked leading to misleading information being given to the end user, or the need to patch the website post-deployment.
Now, the page is auto-configured to point to the release notes pages on the WIKI, of which this page is a part.


@@@@@@@@@@@@@@@@9/13/2012 4:08:37 PM : 10.240.2.79@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

==Summary of Changes
[[TOC]]
== Multiple Version Control System (VCS) Support
== Background
The Release Manager schema and website code have been updated to provide some support for the selection of alternative version control systems. 
Some may already be aware of the potential move away from ClearCase to SubVersion. This seems ever more likely given the high costs associated with ClearCase support, and its poor performance in the area of multi-site development. 
Henceforth, when preparing new package versions, users will need to make a choice between the following version control systems:
 * Uncontrolled
 * ClearCase
 * SubVersion (*)
(*) Initially, SubVersion will not be available. It will be enabled once all of the necessary tools in the development environment have been updated and deployed. This includes the build (daemon) tool and JATS.

Evidence of the new features in Release Manager become apparent when viewing the Release Notes tab for a package version. 

The Package Information section on the page has been modified. It now displays the version control system in use for the package version. And depending upon which VCS is in use, the remaining items in the package information section will differ. For example, if a package version is Uncontrolled, no label or source path fields will be shown.

== Build Standard and Build Environments
Prior to now, users had to click a button next to the "Build Standard" text in the package information display, in order to modify the build standard. This button has now been removed. The build standard and build environments can all be modified within the form that is opended when a user chooses to edit the package information (see below).

== Modifying Package Information
The form used to edit package information has now changed in the following ways:
 * A new VCS selection combo box is shown
 ** Select Uncontrolled if your source is not in ClearCase and you intend to perform some kind of local manual build publishing artifacts directly into dpkg_archive (or if your source is in ClearCase but because you are going to do a manual build, you do not need to publicise its label or location for the build daemon tools). This choice has been made available to reflect the fact that many package versions have been created in the past that seemed to be like this. Mostly, these seem to be database patches of some kind. Needless to say, our QMS demands that source be controlled to enable reproducibility, and it should be labelled accordingly.
 ** Select ClearCase for all current controlled source. Eventually, you will see SubVersion become available in the combo box, when we are ready to start using it, although at this time we do not have a specific target date for that.
 * VCS Sensitivity
 ** The rows that follow the VCS selection combo box vary depending upon which VCS has been selected
 ** When ClearCase is selected, you will see Label and Source Path input fields.
 ** When Uncontrolled is selected, you will not see any Label or Source Path input fields.
 ** When SubVersion is selected, you will see a SubVersion Tag input field, and no Label or Source Path input fields.
 * A new Build Standard selection combo box is shown
 ** Now users can select the build standard directly on this form instead of previously having to do it in another form.

== Business Rule Changes
Some business rules are in place that users should be aware of. 
NOTE: Not all of these are implemented within the package information editing form. Some become apparent when a user attempts to make the package pending/released.
 * Auto-build package versions must __not__ have a VCS type of Uncontrolled
 * Auto-build package versions must __not__ have a build standard of NONE
 * Auto-build package versions must have at least one build environment selected
 * There is no longer any permissions restriction upon which users can select a build standard of NONE.

== Other Problems Addressed
 * Previously, it was impossible to select build environments Linux + Solaris + Win32 for a package version using a build standard of ANT. This has been fixed.

== Minor Report Tool Changes
The report generation tools within Release Manager have been altered such that the information for "Build Environments" (on those reports that have this) now display 
 *<build standard>, <build machine>
where <build standard> may be NONE, ANT, or JATS
and <build machine> ma


PageData:
==Summary of Changes
[[TOC]]
== Removal of Archive Manager Database Interfacing
All functionality related to the use of the Archive Manager database has been removed.

This includes:
 * The "Archive" menu option in the Admin menu
 * The "Archived History" button

Releases can still be placed in Archive mode. The data will remain in Release Managers database.

The long term plan is to remove the Archive Manager database altogether, since it presents an ongoing  maintainability issue for manager suite development. 

Along with this, new means of managing user data both in the release Manager database and dpkg_archive, will be sought. Initial thoughts on this include implementing some kind of quota system for projects. Also, business rules may be changed both in Release Manager and in external tools affecting how we treat archived releases with respect to managing the ever growing data storage demands it presents us with.

This release is to be accompanided by a change to the Release Manager database, that being one to bring back from the Archive Manager database, all archived package versions. However, only the bare essential information is to be bought back. Additional data can be retrieved later on upon request from end-users. That data will remain available in the Archive Database until such time as the database is deleted whereupon the data will be available in a file kept in \MASS_Dev_Tools\manager_suite_schema\archive_manager. From that file, patches can easily be written to retrieve archived data.


PageData:
==Summary of Changes
[[TOC]]
== Pegging a package in a release
DEVI-048876 put forward a case for the need to bring a package into a release 
 * Without it being auto-buildable within the context of the release
 * Without the need to bring all of its dependencies into the release
 * Without it affecting the ability to auto-build other packages within the release that have a dependency upon it. 
The way this has been done is to allow such a package to be denoted as 'Pegged'. 

=== How To Peg A Package
A package can be pegged using the form that opens from the release notes page when editing the "Ripple Properties'. Note that once a package is pegged, build inclusion and ripple type settings are ignored, since the package will not be auto-built within the context of the release. 

Only 'released' package versions can be pegged.

Given that this might be a mechanism abused by end-users in order to avoid doing the work within a release that they really should do, project teams will be required to make a case to the Technology Core team to have a package denoted as pegged. The GUI element to do this will be disabled for all users except those with the highest level permissions, and such permissions are only given to staff in the Technology Core team. Ultimately, this will be David Purdie or Martin Hunt.

The build-tool will be modified to respect the pegged setting upon a package.
=== Identifying Pegged Packages
Pegged packages will utilise a Green Pin state icon in the environment panels (specifically the Released and  All tabs) on the left hand side of the release manager display when viewing a release. 

Also, once pegged, the Ripple Properties panel on the release notes page will not show the build inclusion and ripple type values, but instead say the version is pegged.
=== What can end-users do?
Once a package is pegged, end-users can:
 * Change the version of it that is in the release
 ** Although under the hood, the pegging attribute has been placed upon a specific version of the package in the release, when replacing the version with another, code exists to transfer the pegging attribute from the old to the new version. So, from an end-user perspective, you can consider it as the package that has been pegged, not the version.
 ** The version of a pegged package in a release can only be changed by end-users. It will never be changed by automated tools.
 ** Changing the version can be done by using:
 *** The "Add Package To This Release" button, or 
 *** The merge manager feature, or
 *** The "Use This Version" button on the version history browser form
 ** Creating an entirely new version of a pegged package in a release will eventually lead to the removal of the pegged package from the release. It will be replaced by the new version once it is built and released. The new version will not be pegged, since to build it all of its dependencies should be in place within the release anyway. There would be no point retaining any pegged attribute.
 * Remove the package from the release
 ** Note that if this is done by mistake, when bringing the package back into the release it will not be pegged and another request has to be made to the Technology Core team to have it re-pegged.
 * Use it as a dependency for other packages in the release
 ** Such other packages will __not__ be directly or indirectly excluded from being auto-built due to the state (good or otherwise) of the pegged package and its dependencies.
 ** There is no need to use the "ignore warnings" feature within the pegged package itself.

When cloning a new release from an existing release, the new release will inherit the pegged package attributes of the existing release.

PrevPageData:
@@@@@@@@@@@@@@@@9/13/2012 4:17:15 PM : 10.240.2.79@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

==Summary of Changes
[[TOC]]
Go back to [Release Manager|ReleaseManager] page



[{TableOfContents}]

== Pegging a package in a release
DEVI-048876 put forward a case for the need to bring a package into a release 
 * Without it being auto-buildable within the context of the release
 * Without the need to bring all of its dependencies into the release
 * Without it affecting the ability to auto-build other packages within the release that have a dependency upon it. 
The way this has been done is to allow such a package to be denoted as 'Pegged'. 

=== How To Peg A Package
A package can be pegged using the form that opens from the release notes page when editing the "Ripple Properties'. Note that once a package is pegged, build inclusion and ripple type settings are ignored, since the package will not be auto-built within the context of the release. 

Only 'released' package versions can be pegged.

Given that this might be a mechanism abused by end-users in order to avoid doing the work within a release that they really should do, project teams will be required to make a case to the Technology Core team to have a package denoted as pegged. The GUI element to do this will be disabled for all users except those with the highest level permissions, and such permissions are only given to staff in the Technology Core team. Ultimately, this will be David Purdie or Martin Hunt.

The build-tool will be modified to respect the pegged setting upon a package.
=== Identifying Pegged Packages
Pegged packages will utilise a Green Pin state icon in the environment panels (specifically the Released and  All tabs) on the left hand side of the release manager display when viewing a release. 

Also, once pegged, the Ripple Properties panel on the release notes page will not show the build inclusion and ripple type values, but instead say the version is pegged.
=== What can end-users do?
Once a package is pegged, end-users can:
 * Change the version of it that is in the release
 ** Although under the hood, the pegging attribute has been placed upon a specific version of the package in the release, when replacing the version with another, code exists to transfer the pegging attribute from the old to the new version. So, from an end-user perspective, you can consider it as the package that has been pegged, not the version.
 ** The version of a pegged package in a release can only be changed by end-users. It will never be changed by automated tools.
 ** Changing the version can be done by using:
 *** The "Add Package To This Release" button, or 
 *** The merge manager feature, or
 *** The "Use This Version" button on the version history browser form
 ** Creating an entirely new version of a pegged package in a release will eventually lead to the removal of the pegged package from the release. It will be replaced by the new version once it is built and released. The new version will not be pegged, since to build it all of its dependencies should be in place within the release anyway. There would be no point retaining any pegged attribute.
 * Remove the package from the release
 ** Note that if this is done by mistake, when bringing the package back into the release it will not be pegged and another request has to be made to the Technology Core team to have it re-pegged.
 * Use it as a dependency for other packages in the release
 ** Such other packages will __not__ be directly or indirectly excluded from being auto-built due to the state (good or otherwise) of the pegged package and its dependencies.
 ** There is no need to use the "ignore warnings" feature within the pegged package itself.

When cloning a new release from an existing release, the new release will inherit the pegged package attributes of the existing release.


PageData:
==Summary of Changes
[[TOC]]
This release contains many small fixes described below:

==  "Make Pending" button confirmation text
Pressing the Make Pending button leads to a confirmation dialog being displayed. The text on that dialog was changed to be more general and so apply to both auto and manual build package versions. Before this, the text implied auto-build only, but in fact the button is used for manual build package versions too, when the release is in restrictive or CCB mode.
==  Package Version Locking/Unlocking
The ability for users to unlock a released package version has been removed. This feature was available to users with high enough privileges, however the feature caused some problems for data consistency and users often forgot to lock the package again later on.
==  "Make Unrelease" and "Remove Package" buttons
Previously these two buttons were made invisible in restricted mode releases. Now however, the buttons remain visible if the user has AlterReleaseContentsInRestrictiveMode privileges. This privilege is available to Administrators.
==  Reversioning Patches
The reversioning form no longer allows you to reversion a patch to an auto-build version. It did not make sense to allow such a reversioning, since any attempt later on to make an auto-build patch released would result in an error anyway. All patches are manual build versions and this was evident looking at the existing database data.

The reversioning form now allows for the patch numbering scheme. So, if you accidently gave the patch the wrong number during its initial creation, you can fix it using the reversioning form.
==  Build Status Form
The build status form now checks to ensure that you are logged in if you attempt to make any changes using the checkboxes and the Include button on the form.

Some errors in the formation of content for the Daemon Status Information table have been fixed. The errors led to misleading or incorrect content being displayed.
==  Release Note Generation
The release note generation processing will now abort if it detects a daemon is building the same or another version of the package for which release notes are required. This is necessary to prevent the file system locking that release note generation performs, from interfering with the ability of the build daemon to perform the build and write the files to dpkg_archive.


PageData:
==Summary of Changes
[[TOC]]
== New Run Level
From DEVI-050527 - The Master daemon stays in run level state 'waiting' when publishing a succesfully built package. 

This is not very informative to the end-user of exactly what the daemon is doing.

To make things more user friendly, a new run level called "publishing" has been created. This state will be used by the daemon when publishing a successfully built package. This version of Release Manager supports the display of this new state.


PageData:
==Summary of Changes
[[TOC]]
== Package Information Display
v3.30.5000.cr of Release Manager introduced the capability to support multiple version control systems.
It is thus up to a user to select which version control system they wish to use. Currently this can be NONE (meaning uncontrolled) or ClearCase. In the future, SubVersion will become an option.

When creating a new version of a package, its content in part is cloned from the preceding version. Many existing versions of packages in the database do not explicitly state what version control system they are using. So, we have to assume that it was either ClearCase (if a package label is present) or Uncontrolled (if no package label).

The logic for making this decision when displaying the Package Information section on the release notes page was slightly amiss in that it did not take into account the state of the package version (ie. whether it was released or not), and so initially, it would display all new manual build WIP versions as Uncontrolled. This did not become a problem as long as users remember to edit the Package Information section to add a label, whereupon they would be forced to select ClearCase as the version control system.

The change in this version of Release Manager addresses this issue, in that the initial display will show the new manual build WIP version as ClearCase version controlled, instead of Uncontrolled.


PageData:
==Summary of Changes
[[TOC]]
== Support for CVS
The website code has had some very basic level support added for users who are using the Concurrent Versions System (CVS) version control system.

This support is to be used only for existing projects that are using CVS.

The future for ERG is still ClearCase, and potentially SubVersion. The current quality standards mandate the use of ClearCase.

Users should note that ERG's build (daemon) tool does not support CVS. All package versions configured for CVS must be manually built.


PageData:
==Summary of Changes
[[TOC]]
== Patch Locking/Unlocking
In version 3.30.8000.cr, the package locking/unlocking feature was removed. 

This was done because there were serious implications for the build system and the consistency of releases when a previously released component was unlocked, modified, and re-locked. For example, subsequent ripple builds of higher level components might occur as a result of a package release. If the lower level package was unlocked, modified, and re-locked, what implications does that have for components already built against the earlier state of the released package, and how is the build tool supposed to know that the modification has happened?

However, some categories of packages are not used as dependencies into higher level components. Mainly, these are database patch components. So, it was agreed that patch versions can be unlocked, modified, and re-locked without a problem. So, the functionality has been re-instated for those types of packages only.

The small icon next to the Status field in the details display of a patch version, will be shown to users who have the UnlockPatch permission (currently team/tech leaders and administrators).

Furthermore, the source code behind the URLs that this button uses has been modified to prevent users who just happen to know the names of those files and are therefore able to manually form the URL plus suitable query string in a browser, from circumventing the permissions and the package type checking that is now in place.


PageData:
==Summary of Changes
[[TOC]]
== Reject from Autobuild Approved state
When a package version is an autobuild type, and has been approved for autobuild (using the Make Release button), it enters a state where users are prevented from editing any of its details. The build daemon(s) will pick up the package version details and build and release it, all being well. 

If all is not well and the build fails, the build daemon(s) will add the package version and build failure details to the "DO NOT RIPPLE" table within the Release Manager database. The consequences of this may be viewed on Release Manager's build status display.

In this new version of Release Manager, and under the circumstances just outlined, a user (permissions allowing) is able to reject the package version back to the work-in-progress state. They may need to do this if the build failure was due to some problem with the meta-data of the package that must be corrected by editing the Package Information on the release notes page.

The rejection is accomplished by selecting the Reject button on the release notes page. Note that initially after autobuild approval, this will not normally be seen. If the build failure circumstances eventuate, the button will be seen but the user may need to refresh the release manager web page first.

The key to displaying the Reject button is that the package version is an autobuild type, it is approved for autobuild, and it is in the "DO NOT RIPPLE" table. There is a way for a user to manually add an entry to the "DO NOT RIPPLE" table. This is possible by opening the ripple properties form and setting "Build Inclusion" to "No". Doing this before approving for autobuild, will result in the Reject button being seen immediately once the autobuild approval is made and the web page refreshes. 

It is vitally important that we prevent any possibility of rejecting the package version back to work-in-progress if there is any chance that a build daemon might start work upon it simulataneously. The use of the "DO NOT RIPPLE" table is one of the only ways of doing this.

When a user rejects a package version back to work-in-progress, the entry in the "DO NOT RIPPLE" table is removed automatically, only if it appears to have resulted from a build failure. Thus, if a user sets "Build Inclusion" to "No", this will remain in place even after they reject the package back to work-in-progress from the autobuild approved state. 
Similarly, if the entry in the "DO NOT RIPPLE" table is a result of an indirect build failure, it will remain.
!Permission Issues
In an OPEN mode release, a Developer may use the Reject button.
In a CCB/RESTRICTED mode release, a Team/Tech Leader or administrator may use the Reject button 
NOTE: This is correct at time of writing but may change subsequently if permission control object vs. role relationships are modified in Access Manager.

== New Project
A new project has started called "New Delhi". This has been given the package version extension of "ndl".


PageData:
==Summary of Changes
[[TOC]]
== Build and Release
Correct the building of the Release Manager. Correct the filtering of several jats-internal files including the .svn directory.

PrevPageData:
@@@@@@@@@@@@@@@@10/29/2012 1:21:57 PM : 10.240.2.79@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

==Summary of Changes
[[TOC]]
== Release Notes
The release notes now have a nice icon in the banner. Clicking on the icon will take the user to the Release Notes Home Page.
== Development Notes
Extended the Release Manager Wiki to contain a set of pages devoted to the development of Release Manager. These pages are not available on the production system
== Release Manager Page Header
All pages generated by the Release Manager Web Server now have their header generated by the one piece of code.
This has allowed the header to contain a warning banner if the user is using a Test or Development version of either the Web Server or the Database.
There are two forms of banner:

>* {red}Red{/red}: Indicates that the database in use if the Live Release Manager Database
>* {green}Green{/green}: Indicates that the database is not the Live Database.
== Package Release Process
The Release Process has been enhanced to detect the problem where a package has been migrated to Subversion, but the version of the package that
is about to be released is not under Subversion. The package cannot be released.
== Minor Improvements
>* Build Status page has a link to refresh the page
>* Validity checking of a ClearCase path ensures that they start with a /
>* Very long subversion tags are now displayed correctly. There was a problem with tags greater that 127 characters.
>* Added project suffix: '.mbu'

@@@@@@@@@@@@@@@@10/29/2012 1:19:13 PM : 10.240.2.79@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

==Summary of Changes
[[TOC]]
== Release Notes
The release notes now have a nice icon in the banner. Clicking on the icon will take the user to the Release Notes Home Page.
== Development Notes
Extended the Release Manager Wiki to contain a set of pages devoted to the development of Release Manager. These pages are not available on the production system
== Release Manager Page Header
All pages generated by the Release Manager Web Server now have their header generated by the one piece of code.
This has allowed the header to contain a warning banner if the user is using a Test or Development version of either the Web Server or the Database.
There are two forms of banner:
>* {red}Red{/red}: Indicates that the database in use if the Live Release Manager Database
>* {green}Green{/green}: Indicates that the database is not the Live Database.
== Minor Improvements
>* Build Status page has a link to refresh the page
>* Validity checking of a ClearCase path ensures that they start with a /
>* Very long subversion tags are now displayed correctly. There was a problem with tags greater that 127 characters.
>* Added project suffix: '.mbu'

@@@@@@@@@@@@@@@@9/27/2012 3:05:42 PM : 10.240.2.79@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

==Summary of Changes
[[TOC]]
== Release Notes
The release notes now have a nice icon in the banner. Clicking on the icon will take the user to the Release Notes Home Page.
== Development Notes
Extended the Release Manager Wiki to contain a set of pages devoted to the development of Release Manager. These pages are not available on the production system
== Release Manager Page Header
All pages generated by the Release Manager Web Server now have their header generated by the one piece of code.
This has allowed the header to contain a warning banner if the user is using a Test or Development version of either the Web Server or the Database.
There are two forms of banner:

>* {red}Red{/red}: Indicates that the database in use if the Live Release Manager Database
>* {green}Green{/green}: Indicates that the database is not the Live Database.
== Minor Improvements
>* Build Status page has a link to refresh the page
>* Validity checking of a ClearCase path ensures that they start with a /
>* Very long subversion tags are now displayed correctly. There was a problem with tags greater that 127 characters.

@@@@@@@@@@@@@@@@9/27/2012 2:46:22 PM : 10.240.2.79@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

==Summary of Changes
[[TOC]]
== Release Notes
The release notes now have a nice icon in the banner. Clicking on the icon will take the user to the Release Notes Home Page.
== Development Notes
Extended the Release Manager Wiki to contain a set of pages devoted to the development of Release Manager. These pages are not available on the production system
== Release Manager Page Header
All pages generated by the Release Manager Web Server now have their header generated by the one piece of code.
This has allowed the header to contain a warning banner if the user is using a Test or Development version of either the Web Server or the Database.
There are two forms of banner:
>* {red}Red{/red}: Indicates that the database in use if the Live Release Manager Database
>* {green}Green{/green}: Indicates that the database is not the Live Database.
== Minor Improvements
>* Build Status page has a link to refresh the page
>* Validity checking of a ClearCase path ensures that they start with a /

@@@@@@@@@@@@@@@@9/27/2012 2:46:02 PM : 10.240.2.79@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

==Summary of Changes
[[TOC]]
== Release Notes
The release notes now have a nice icon in the banner. Clicking on the icon will take the user to the Release Notes Home Page.
== Development Notes
Extended the Release Manager Wiki to contain a set of pages devoted to the development of Release Manager. These pages are not available on the production system
== Release Manager Page Header
All pages generated by the Release Manager Web Server now have their header generated by the one piece of code.
This has allowed the header to contain a warning banner if the user is using a Test or Development version of either the Web Server or the Database.
There are two forms of banner:
>* {red}Red</red}: Indicates that the database in use if the Live Release Manager Database
>* Green: Indicates that the database is not the Live Database.
== Minor Improvements
>* Build Status page has a link to refresh the page
>* Validity checking of a ClearCase path ensures that they start with a /

@@@@@@@@@@@@@@@@9/27/2012 2:44:54 PM : 10.240.2.79@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

==Summary of Changes
[[TOC]]
== Release Notes
The release notes now have a nice icon in the banner. Clicking on the icon will take the user to the Release Notes Home Page.
== Development Notes
Extended the Release Manager Wiki to contain a set of pages devoted to the development of Release Manager. These pages are not available on the production system
== Release Manager Page Header
All pages generated by the Release Manager Web Server now have their header generated by the one piece of code.
This has allowed the header to contain a warning banner if the user is using a Test or Development version of either the Web Server or the Database.
There are two forms of banner:
>* Red: Indicates that the database in use if the Live Release Manager Database
>* Green: Indicates that the database is not the Live Database.
== Minor Improvements
>* Build Status page has a link to refresh the page
>* Validity checking of a ClearCase path ensures that they start with a /

@@@@@@@@@@@@@@@@9/26/2012 3:17:38 PM : 10.240.2.79@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

==Summary of Changes
[[TOC]]
== Release Notes
The release notes now have a nice icon in the banner. Clicking on the icon will take the user to the Release Notes Home Page.
== Development Notes
Extended the Release Manager Wiki to contain a set of pages devoted to the development of Release Manager. These pages are not available on the production system
== Release Manager Page Header
All pages generated by the Release Manager Web Server now have their header generated by the one piece of code.
This has allowed the header to contain a warning banner if the user is using a Test or Development version of either the Web Server or the Database.
There are two forms of banner:
>* Red: Indicates that the database in use if the Live Release Manager Database
>* Green: Indicates that the database is not the Live Database.

@@@@@@@@@@@@@@@@9/24/2012 10:11:54 AM : 10.240.2.79@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

==Summary of Changes
[[TOC]]
== Release Notes
The release notes now have a nice icon in the banner. Clicking on the icon will take the user to the Release Notes Home Page.
== Development Notes
Extended the Release Manager Wiki to contain a set of pages devoted to the development of Release Manager. These pages are not available on the production system

@@@@@@@@@@@@@@@@9/14/2012 4:46:10 PM : 10.240.2.79@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

==Summary of Changes
[[TOC]]
== Release Notes
The release notes now have a nice icon in the banner. Clicking on the icon will take the user to the Release Notes Home Page.


PageData:
==Summary of Changes
[[TOC]]
== Release Notes
The release notes now have a nice icon in the banner. Clicking on the icon will take the user to the Release Notes Home Page.
== Development Notes
Extended the Release Manager Wiki to contain a set of pages devoted to the development of Release Manager. These pages are not available on the production system
== Release Manager Page Header
All pages generated by the Release Manager Web Server now have their header generated by the one piece of code.
This has allowed the header to contain a warning banner if the user is using a Test or Development version of either the Web Server or the Database.
There are two forms of banner:

>* {red}Red{/red}: Indicates that the database in use if the Live Release Manager Database
>* {green}Green{/green}: Indicates that the database is not the Live Database.
== Package Release Process
The Release Process has been enhanced to detect the problem where a package has been migrated to Subversion, but the version of the package that
is about to be released is not under Subversion. The package cannot be released.
== Minor Improvements
>* Build Status page has a link to refresh the page
>* Validity checking of a ClearCase path ensures that they start with a /
>* Very long subversion tags are now displayed correctly. There was a problem with tags greater that 127 characters.
>* Added project suffix: '.mbu'


PageData:
==Summary of Changes
[[TOC]]
== Default project suffix for new package-versions
The default suffix for a new package-version is now '.cr'. Previously it was the first entry in the list, which was '.bei'.
== JATS extraction commands for unsupported Version Control Systems
The Release Notes highlight package versions where the Version Control System is not supported by the JATS extraction commands.

JATS extraction commands will not be generated for package versions not controlled by a Version Control System supported by JATS, the Build Daemons and Release Manager.

PrevPageData:
@@@@@@@@@@@@@@@@1/3/2013 1:46:48 PM : 10.240.2.79@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

==Summary of Changes
[[TOC]]
== Default project suffix for new package-versions
The default suffix for a new package-version is now '.cr'. Previously it was the first entry in the list, which was '.bei'.
== JATS extraction commands for unsupported Version Control Systems
The Release Notes will highlight package versions where the Version Control System is not supported by the JATS extraction commands.

@@@@@@@@@@@@@@@@11/22/2012 12:46:00 PM : 10.240.2.79@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

==Summary of Changes
[[TOC]]
== Default project suffix for new package-versions
The default suffix for a new package-version is now '.cr'. Previously it was the first entry in the list, which was '.bei'.

@@@@@@@@@@@@@@@@11/22/2012 12:44:30 PM : 10.240.2.79@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@


PageData:
==Summary of Changes
[[TOC]]
== New Project Suffix
 * bes - Besancon Project
== Default Version Control System
The default version control system for new packages is 'Subversion'. This reflects the move away from 'ClearCase' as the primary Version Control System.
== Locking and Unlocking a package
Corrected code that allowed privileged users to lock and unlock a package from the 'Release Notes. This feature is not used often, but sometime Release Manager gets a bit confused about the state of a package.
== Internal Tests
Created an admin page to run various tests and indicate the results. So far the tests include
 * Map dpkg_archive to the Web Server Drive Space
 * Remote Execute a command on the package server
== Remote Execution
The Release Manager Web Site perform remote execution of commands on a Unix Server. The remote execution method has been changed from 'rexec' to 'ssh'. This has been done to facilitate the migration to 'auperaarc01' as the primary package server.

PrevPageData:
@@@@@@@@@@@@@@@@5/7/2013 4:46:38 PM : 10.240.2.79@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

==Summary of Changes
[[TOC]]
== Locking and Unlocking a package
Corrected code that allowed privileged users to lock and unlock a package from the 'Release Notes. This feature is not used often, but sometime Release Manager gets a bit confused about the state of a package.
== Internal Tests
Created an admin page to run various tests and indicate the results. So far the tests include
 * Map dpkg_archive to the Web Server Drive Space
 * Remote Execute a command on the package server
== Default Version Control System
The default version control system for new packages is 'Subversion'. This reflects the move away from 'ClearCase' as the primary Version Control System.
== Remote Execution
The Release Manager Web Site perform remote execution of commands on a Unix Server. The remote execution method has been changed from 'rexec' to 'ssh'. This has been done to facilitate the migration to 'auperaarc01' as the primary package server.

@@@@@@@@@@@@@@@@5/7/2013 4:01:27 PM : 10.240.2.79@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

==Summary of Changes
[[TOC]]
== Locking and Unlocking a package
Corrected code that allowed privileged users to lock and unlock a package from the 'Release Notes. This feature is not used often, but sometime Release Manager gets a bit confused about the state of a package.

== Internal Tests
Created an admin page to run various tests and indicate the results. So far the tests include
 * Map dpkg_archive to the Web Server Drive Space
 * Remote Execute a command on the package server

== Default Version Control System
The default version control system for new packages is 'Subversion'. This reflects the move away from 'ClearCase' as the primary Version Control System.

@@@@@@@@@@@@@@@@5/7/2013 3:59:58 PM : 10.240.2.79@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

==Summary of Changes
[[TOC]]
== Locking and Unlocking a package
Corrected code that allowed privileged users to lock and unlock a package from the 'Release Notes. This feature is not used often, but sometime Release Manager gets a bit confused about the state of a package.

== Internal Tests
Created an admin page to run various tests and indicate the results. So far the tests include
 * Map dpkg_archive to the Web Server Drive Space
 * Remote Execute a command on the package server

@@@@@@@@@@@@@@@@1/24/2013 5:09:55 PM : 10.240.2.79@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

==Summary of Changes
[[TOC]]
== Locking and Unlocking a package
Corrected code that allowed privileged users to lock and unlock a package from the 'Release Notes. This feature is not used often, but sometime Release Manager gets a bit confused about the state of a package.

@@@@@@@@@@@@@@@@1/24/2013 5:09:29 PM : 10.240.2.79@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

==Summary of Changes
[[TOC]]
== Corrected code that allowed privileged users to lock and unlock a package from the 'Release Notes. This feature is not used often, but sometime Release Manager gets a bit confused about the state of a package.


PageData:
==Summary of Changes
[[TOC]]
== ClearQuest interface
All of the ClearQuest databases have been switched off, except for the DEVI database.

Support for the unavailable databases has been removed from Release Manager
== Improved the process of adding Packages to a Release
The dialog has been reworked to greatly simplify the process. The user is limited to adding an existing version to the Release.
It is not possible to directly add a new version to the Release. This should be achieved by first adding an existing version and then creating a new version based on the existing version.
== Improved the process of creating a New Package
This has been streamlined and merged into the process of creating a new package version. The default is to create an new version with automated versioning. This was not possible in the previous release.
== Improved the process of creating a New Package Version
This has been streamlined and the dialog improved.
== Improved the dependency editor
Selecting a package-version created a popup window to provide the version selection. This is now done within the form.
== Improved support for packages with non-standard version numbers
>* Packages with a 'tool' extension will be treated in the same manner as 'cots' packages.
This has been done as some of the build system tools are really COTS packages that have been wrapped in VIX friendly installers.
>* Automated versioning of 'tool' and 'cots' package
This has been extended to allow three modes of operation:
>>* Same as normal packages - if the version number is in the normal Major.Minor.Patch-Build format (ie: 1.0.0000)
>>* Ripple Patch Number - if the version number has a 'patch-build' component (ie: xxxxx.0000).
>>* Force Manual build - if the version number is none of the above
== Removed referenced to deploy_archive
The deploy_archive and dpkg_archive have long since been merged into one.

Release Manager guessed where a package may be located based on its name. This was often incorrect.

All references to the package store are now via 'dpkg_archive'.
== Correct bug in editing Release Notes for a Release Package-Version
If the Package Information of the Release Notes tab was edited and the package-version had been released, then the Subversion Tag entry would be lost. This has been fixed.
== Project Suffix Creation and Editing
Until now project suffixes have been hard coded into the Release Manager code. This made is difficult to add new project suffixes. This has been corrected and now the project suffixes are stored in the Release Manager database and can be created and edited via the Web Interface. Creation and editing is an admin task and its access is restricted.

Project Suffixes have the following fields:
>* Suffix. Must start with a '.'. It must be 2 to 4 lower case characters. ie: '.cots'
>* Comment. A short comment that will be displayed as a part of the selection process
>* Free Form Version Flag. A boolean flag that indicates that this package type is allowed to have non-standard version numbers. This is reserved for COTS and TOOL packages. When set a new package version does not support full automatic version number allocation. 
>>* If the version number ends in a Patch and Build Number, then the new version can support automated Patch number generation. A new version can be created automatically and the package can be ripple built.
>>* If the version number does not end in a Patch and Build Number, then the package's new version number must be manually allocated. The package cannot be rippled, although the package can still be released and built by the build system.
>* Visibility Flag. A boolean flag that allows the suffix to be hidden in selection displays. This allows some legacy package suffixes to be retained in the database, but not used for new packages.
== Display Files and Folders on the History Page
The 'History' page now displays the package-versions files and folders in the same manner as the Main Package Display, although the comparison dialog is suppressed in line with other displays on the 'History' Page.
== Deprecate old Package Version Scheme
Packages that 'looked' like deployed package, and were not a part of the Stockholm Project, would be given a default label like: MAS_MYPACKAGE_121200.
All other packages were given a default label of MyPackage_12.12.00.mas.

This has been removed. Now all packages are given a default simple label created by joining the package name, package version and project suffix. ie: MyPackage_12.12.00.mas.
== Fix Dependency Importer for Jants and Ant style Packages
The dependency importer, once again, supports the Jants and Ant style format. This was broken some time back.
== Split the "Make Release" button into two buttons
The "Make Release" Button image was being used for two different purposes. The two purposes now have two images:

>* Make Release - Where the Package-Version will be released directly
>* Build Package - Where the Package-Version has been approved and is ready to be built by the build Daemons.
== Expand the Package-Version State in the Release Notes
Previously the "Release Notes" tab contained a "Status" field that indicated in the package was "Released" or "Not Released". This has been extended to indicate more information on the package state. The "Not Released" states have been expanded. Note: They are not always correct and this display will assist in tracking down inconsistencies.
== Improved the Build Status display
Added two check boxes to selectively show and hide parts of the build status. The users selection is remembered for future use. The two buttons are:
>* Show Config Errors. This allows the static configuration errors to be shown or hidden. These errors are problems caused by a misconfiguration between the package and the release.
>* Show Build Errors . This allows the build errors to be shown or hidden.
== Email Notifications
Consolidate Email Sending into one function that uses the configured SMTP host for email transfer.
== Merged the Help and About Menus
Extended the Help Menu and in the process merged the About Menu into the Help Menu.
== Extended Admin Menu
Extended the Admin Menu to:
>* Include an Add Project action. This was available elsewhere, but not in an obvious location.
.* Group the actions into logical groups
== Improved Menu behaviour
Improved the behaviour of the menus. The menu is anchored to the parent menu and not the mouse position. This prevents the popup menus from moving around.
Corrected the window size calculations to allow the menu to be positioned correctly when near the edge of the screen.
== Common footer to error messages
Previously many of the error messages had a page footer built into each message. This varied from message to message and was different to the main pages. This release uses a common code block to generate the page footer.
== Release Note Editing of Previous Version
The list of versions is now sorted according to Major, Minor, Patch, Build and Project Suffix. Previously the list was textually sorted. This made selection difficult.
== User Logon and Domain Authentication
The logon process now uses the Domain Name provided by Access Manager. This feature was disabled when the corporate domain name was changed from ERG to VIX. 
== Addressed several shortcomings in the Logon and Password Management
In the Logon process:
>* Made the two logon forms consistent.
>* Both check for the presence of a username and any required password.

In the User Maintenance pages:
>* Users that authenticate against the domain cannot change the domain related information
>* User password cannot be set if the user authenticates against the domain. The user is now informed of this before the entering data.

Added support to assist in developing pages with access control features:
>*when using the test database user authentication always succeeds as long as the user name is known to access manager.
>*prompt for password is disabled
== User Notifications Display
Address some usability issues in the User Notification Display
>* Split it into two pages.
>>* One for Packages owned by the user
>>* One for packages that the user is interested in
>* Addressed display issues in the list of packages owned by the user:
>>* Sorting order corrected to allow grouping of packages in the display
>>* Prevent line wrapping within the package version names and the Release names
>>* Allow the table to use more of the screen width
== User Roles Display
This display has been extended to show the detailed user access operations. These are of little value to most users, but are useful in diagnosing access issues as it shows the individual access control permissions for a given project.

PrevPageData:
@@@@@@@@@@@@@@@@8/7/2013 12:00:15 PM : 10.240.2.79@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

==Summary of Changes
[[TOC]]
== Improved the process of adding Packages to a Release
The dialog has been reworked to greatly simplify the process. The user is limited to adding an existing version to the Release.
It is not possible to directly add a new version to the Release. This should be achieved by first adding an existing version and then creating a new version based on the existing version.
== Improved the process of creating a New Package
This has been streamlined and merged into the process of creating a new package version. The default is to create an new version with automated versioning. This was not possible in the previous release.
== Improved the process of creating a New Package Version
This has been streamlined and the dialog improved.
== Improved the dependency editor
Selecting a package-version created a popup window to provide the version selection. This is now done within the form.
== Improved support for packages with non-standard version numbers
>* Packages with a 'tool' extension will be treated in the same manner as 'cots' packages.
This has been done as some of the build system tools are really COTS packages that have been wrapped in VIX friendly installers.
>* Automated versioning of 'tool' and 'cots' package
This has been extended to allow three modes of operation:
>>* Same as normal packages - if the version number is in the normal Major.Minor.Patch-Build format (ie: 1.0.0000)
>>* Ripple Patch Number - if the version number has a 'patch-build' component (ie: xxxxx.0000).
>>* Force Manual build - if the version number is none of the above
== Removed referenced to deploy_archive
The deploy_archive and dpkg_archive have long since been merged into one.

Release Manager guessed where a package may be located based on its name. This was often incorrect.

All references to the package store are now via 'dpkg_archive'.
== Correct bug in editing Release Notes for a Release Package-Version
If the Package Information of the Release Notes tab was edited and the package-version had been released, then the Subversion Tag entry would be lost. This has been fixed.
== Project Suffix Creation and Editing
Until now project suffixes have been hard coded into the Release Manager code. This made is difficult to add new project suffixes. This has been corrected and now the project suffixes are stored in the Release Manager database and can be created and edited via the Web Interface. Creation and editing is an admin task and its access is restricted.

Project Suffixes have the following fields:
>* Suffix. Must start with a '.'. It must be 2 to 4 lower case characters. ie: '.cots'
>* Comment. A short comment that will be displayed as a part of the selection process
>* Free Form Version Flag. A boolean flag that indicates that this package type is allowed to have non-standard version numbers. This is reserved for COTS and TOOL packages. When set a new package version does not support full automatic version number allocation. 
>>* If the version number ends in a Patch and Build Number, then the new version can support automated Patch number generation. A new version can be created automatically and the package can be ripple built.
>>* If the version number does not end in a Patch and Build Number, then the package's new version number must be manually allocated. The package cannot be rippled, although the package can still be released and built by the build system.
>* Visibility Flag. A boolean flag that allows the suffix to be hidden in selection displays. This allows some legacy package suffixes to be retained in the database, but not used for new packages.
== Display Files and Folders on the History Page
The 'History' page now displays the package-versions files and folders in the same manner as the Main Package Display, although the comparison dialog is suppressed in line with other displays on the 'History' Page.
== Deprecate old Package Version Scheme
Packages that 'looked' like deployed package, and were not a part of the Stockholm Project, would be given a default label like: MAS_MYPACKAGE_121200.
All other packages were given a default label of MyPackage_12.12.00.mas.

This has been removed. Now all packages are given a default simple label created by joining the package name, package version and project suffix. ie: MyPackage_12.12.00.mas.
== Fix Dependency Importer for Jants and Ant style Packages
The dependency importer, once again, supports the Jants and Ant style format. This was broken some time back.
== Split the "Make Release" button into two buttons
The "Make Release" Button image was being used for two different purposes. The two purposes now have two images:

>* Make Release - Where the Package-Version will be released directly
>* Build Package - Where the Package-Version has been approved and is ready to be built by the build Daemons.
== Expand the Package-Version State in the Release Notes
Previously the "Release Notes" tab contained a "Status" field that indicated in the package was "Released" or "Not Released". This has been extended to indicate more information on the package state. The "Not Released" states have been expanded. Note: They are not always correct and this display will assist in tracking down inconsistencies.
== Improved the Build Status display
Added two check boxes to selectively show and hide parts of the build status. The users selection is remembered for future use. The two buttons are:
>* Show Config Errors. This allows the static configuration errors to be shown or hidden. These errors are problems caused by a misconfiguration between the package and the release.
>* Show Build Errors . This allows the build errors to be shown or hidden.
== Email Notifications
Consolidate Email Sending into one function that uses the configured SMTP host for email transfer.
== Merged the Help and About Menus
Extended the Help Menu and in the process merged the About Menu into the Help Menu.
== Extended Admin Menu
Extended the Admin Menu to:
>* Include an Add Project action. This was available elsewhere, but not in an obvious location.
.* Group the actions into logical groups
== Improved Menu behaviour
Improved the behaviour of the menus. The menu is anchored to the parent menu and not the mouse position. This prevents the popup menus from moving around.
Corrected the window size calculations to allow the menu to be positioned correctly when near the edge of the screen.
== Common footer to error messages
Previously many of the error messages had a page footer built into each message. This varied from message to message and was different to the main pages. This release uses a common code block to generate the page footer.
== Release Note Editing of Previous Version
The list of versions is now sorted according to Major, Minor, Patch, Build and Project Suffix. Previously the list was textually sorted. This made selection difficult.
== User Logon and Domain Authentication
The logon process now uses the Domain Name provided by Access Manager. This feature was disabled when the corporate domain name was changed from ERG to VIX. 
== Addressed several shortcomings in the Logon and Password Management
In the Logon process:
>* Made the two logon forms consistent.
>* Both check for the presence of a username and any required password.

In the User Maintenance pages:
>* Users that authenticate against the domain cannot change the domain related information
>* User password cannot be set if the user authenticates against the domain. The user is now informed of this before the entering data.

Added support to assist in developing pages with access control features:
>*when using the test database user authentication always succeeds as long as the user name is known to access manager.
>*prompt for password is disabled
== User Notifications Display
Address some usability issues in the User Notification Display
>* Split it into two pages.
>>* One for Packages owned by the user
>>* One for packages that the user is interested in
>* Addressed display issues in the list of packages owned by the user:
>>* Sorting order corrected to allow grouping of packages in the display
>>* Prevent line wrapping within the package version names and the Release names
>>* Allow the table to use more of the screen width
== User Roles Display
This display has been extended to show the detailed user access operations. These are of little value to most users, but are useful in diagnosing access issues as it shows the individual access control permissions for a given project.


PageData:
Table of Contents
[[TOC]]
== Release Manager Tests
>* Added additional information: User ID, User name, email address
>* Added email test. With and without an attachment.
>* The tests are performed on demand, rather than when the page is loaded
>* Added access control to the tests
== Location of Daemon Status
The daemon status displayed in a package versions action bar has been moved to the far left. Previously it floated around a bit. 
== Emailing users
Consolidated emailing operations and corrected some issues associated with emailing
== Release Difference Reports
>* Expanded the page header to show the Project, Branch and BOM Version.
>* Added Jira Issues.
>>* Previously the report only included issues from ClearQuest. This change adds issues that have been held in Jira. The extraction is still experimental. 
>* Fixed issues with the Expand/Collapse of sections.
>>* Previously, do to incorrect HTML, only a part of the section would collapse.
>* Add a control to Expand and Collapse all sections in the report

PrevPageData:
@@@@@@@@@@@@@@@@8/23/2013 4:55:19 PM : 10.240.2.79@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

Table of Contents
[[TOC]]
== Release Manager Tests
>* Added additional information: User ID, User name, email address
>* Added email test. With and without an attachment.
>* The tests are performed on demand, rather than when the page is loaded
>* Added access control to the tests
== Location of Daemon Status
The daemon status displayed in a package versions action bar has been moved to the far left. Previously it floated around a bit. 
== Emailing users
Consolidated emailing operations and corrected some issues associated with emailing

@@@@@@@@@@@@@@@@8/13/2013 2:02:28 PM : 10.240.2.79@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

Table of Contents
[[TOC]]
== Release Manager Tests
>* Added additional information: User ID, User name, email address
>* Added email test. With and without an attachment.
>* The tests are performed on demand, rather than when the page is loaded
>* Added access control to the tests
== Location of Daemon Status
The daemon status displayed in a package versions action bar has been moved to the far left. Previously it floated around a bit. 

@@@@@@@@@@@@@@@@8/13/2013 2:01:39 PM : 10.240.2.79@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

Table of Contents
[[TOC]]
== Release Manager Tests
*> Added email test. With and without an attachment.
*> The tests are performed on demand, rather than when the page is loaded

== Location of Daemon Status
The daemon status displayed in a package versions action bar has been moved to the far left. Previously it floated around a bit. 

@@@@@@@@@@@@@@@@8/8/2013 11:18:40 AM : 10.240.2.79@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

Table of Contents
[[TOC]]
== Location of Daemon Status
The daemon status displayed in a package versions action bar has been moved to the far left. Previously it floated around a bit.


