Changes

|}

|}

The verification phase taking place before release should pick up hard dependencies which could break an update. To the best of my understanding, the 'Verified Package Versions' tab in Rnotes will track hard dependencies - it does what Ian Wells used to do normally and try to build a bug and package dependency graph <span style="color: red;">To be confirmed</span>.

There are two types of package dependency to check before a release can take place:

What needs to be checked manually is where a package fixes three bugs and one was not verified, the so-called soft dependencies. It means that only an older version of that package can be released. Also it can affect other packages if one of the fixes involved multiple packages. <span style="color: red;">To be confirmed</span>

:a) Hard dependencies. These dependencies are specified in the spec file, eg: requires: e-smith-lib >= 2.0.0-2. Developers put these in when it is necessary to enforce dependencies between packages. The verification phase taking place before release should pick up hard dependencies which could break an update - this is what testing of new package(s) is all about. To the best of my understanding, the 'Verified Package Versions' tab in Rnotes does not track hard dependencies. <span style="color: red;">To be confirmed</span>.

The difference between "hard" and "soft" dependencies referred to in this document are:

:b) Soft dependencies. These dependencies occur when a package fixes three bugs and one of them has not been verified. As a result, and until all bugs associated with a particular package are verified, only an older version of that package can be safely released. Also note that unresolved soft dependencies may affect other packages if one of the fixes involves multiple packages. Luckily the 'Verified Package Versions' tab in Rnotes will track this - Rnote script do what Ian Wells used to do manually and try to build a bug and package dependency graph.

:a) Hard dependencies are those from the spec file, eg: requires: e-smith-lib >= 2.0.0-2

 

Developers put these in when it is necessary to enforce dependencies between packages.

 

:b) Soft dependencies relates to ....  <span style="color: red;">needs a definition</span>

As an illustration of soft deps, consider the following scenario, actual bug numbers etc are made up for this example:

As an illustration of soft deps, consider the following scenario, actual bug numbers etc are made up for this example:

*e-smith-base 5.0.0-16 cannot be released as it has a change that has not been verified.  

*e-smith-base 5.0.0-16 cannot be released as it has a change that has not been verified.  

**It would be possible to release e-smith-base 5.0.0-14

*It may be possible to release e-smith-base 5.0.0-14

*e-smith-pop3 2.0.0-2 cannot be released as e-smith-base 5.0.0-16 which contains part of the fix for bug 6262 is not being released.

*e-smith-pop3 2.0.0-2 cannot be released as e-smith-base 5.0.0-16 which contains part of the fix for bug 6262 is not being released.

*e-smith-apache 2.0.0-7 cannot be released as part of the fix for Bug 4633 is in e-smith-pop3 2.0.0-1 which is not being released.

*e-smith-apache 2.0.0-7 cannot be released as part of the fix for Bug 4633 is in e-smith-pop3 2.0.0-1 which is not being released.

If you carefully check the code changes it may be possible to release e-smith-pop3 and e-smith-apache in the example above, but safest not to do so.

If you carefully check the code changes it may be possible to release e-smith-pop3 and e-smith-apache in the example above, but safest not to do so.

Note: Shad's automated script doesn't do any blocking of packages.  It just tries to sort out where packages should belong based on where things exist when it starts running.

Note: Shad's automated script doesn't do any blocking of packages.  It just tries to sort out where packages should belong based on where things exist when it starts running. Accordingly, the script does not prevent the release of packages for which package dependencies have not been resolved.

{| style="color:red;background-color:#ffffcc;"

{| style="color:red;background-color:#ffffcc;"