How versioning is defined

JBoss Portal follows the versioning system defined by JBoss Product Versioning. Each minor release (2.0, 2.2, etc...) has a branch which contains bug fixes only. For example 2.0.1 fixes bugs in 2.0 and does not add new features to it.

How to use versions on a JIRA issue

Here we define how to use the concept of versions with the project, indeed each JIRA issue defines

1. The affect version : this is the version(s) an issue 'applies' to. For instance, a bug might affect versions 1.1 and 1.2.

2. The fix for version : this is the version the issue was or will be fixed in. For instance, the bug affecting 1.1 and 1.2 might be fixed in 2.0. This is the most important field to properly fill.

It is very important to understand how to use these concepts properly with the JBoss Portal project in order to cope with the different versions.

How to properly fill the fix for field

This field contains a subset of the current release available :

1. It can be unscheduled (zero fix version chosen)

2. A subset of the current release available

When an issue is unscheduled it means that we consider the issue (we know it exist) but for now there is nothing planned for its resolution.

When an issue is scheluded it must follow the rules :

1. Many version can be selected but at most one version per branch must be selected.

2. For a selected branch the selected version is either

1. A branch release

2. A tag release

-

Release

Release entries are created for each intermediate release (alpha, beta, CRx, GA). Versions are created in JIRA whenever it's needed. So, for instance, when we start working on 2.6, "2.6.Alpha1" version is created, and appropriate JIRA tasks need to be assigned to this version.

Tasks which are not mapped to a specific intermediate release can me mapped to the Final release. However, it's suggested to assign tasks to appropriate intermediate version as soon as possible.

By definition, Alpha release is supposed to be feature complete. So all new feature tasks should have Fix Version set to one of the Alpha versions. Bug fixes can be done in Beta.

Developer releases (DR) don't need to be reflected in JIRA unless it's necessary.

Whenever we release a version, JIRA takes care of moving remaining open issues to the next unreleased version. JIRA will prompt you which version you want to re-assign open issues to.

-

Examples

There is a bug which occurs in 2.0, 2.0.1 but does not occur in 2.2, no new release of 2.0 is planned yet

• Affect version : 2.0.0 and 2.0.1.

• Fix for version : Branch 2.0.

Same as before but 2.0.1 is scheduled for within one month

• Affect version : 2.0.0, 2.0.1 and 2.0.2.

• Fix for version : 2.0.2 or Branch 2.0, if it is in Branch 2.0 later it can be moved to 2.0.x when a release is done, 2.0.3 for instance.

There is a new feature needed in the next minor release 2.4 but only the Branch 2.4 release exist

• Affect version : Branch 2.4.

• Fix version : Branch 2.4, it will be moved to 2.4 later.

There is a new feature to be implemented in 2.6 release.

• Affect version : 2.4 Final

• Fix version : 2.6.Alpha1

There is a bug fix that need to be done in 2.6 release. This can wait until Beta. Next 2.4 release is not scheduled yet.

• Affect version : Branch 2.4.

• Fix version : Branch 2.4, 2.6.Beta1

todo : add other examples.