Re: [mantisbt-dev] policy for 1.0.x branch further development

[Victor B. <vb...@gm...>]

Hi Gianluca,

Thanks for raising this issue.  I agree with you that we need a clear
definition of what should be merged in 1.0.x branch and what
shouldn't.

So far I've been porting issues like:
1. Security Bugs
2. Bugs that are deployment stoppers - blank screens, installation
issues, Linux distribution issues.
3. Bugs that are generating a lot of support.

Feel free to suggest other categories that should fall in the above list.

The reason that I am trying to control the above list is to achieve two things:

1. Keep the development resources focused on dev branch, and less porting.
2. Keep the 1.0.x branch very stable and hence make it a no brainer
for users to upgrade when they find a new 1.0.x branch without
breaking their installation.

As for the status of the 1.1.x branch, the plan is as follows:

1. Release 1.1.0a4 very soon (maybe within a week).
2. Hopefully the following release will be rc1 and at this point we branch.
3. New features then go on 1.2.x branch and fixes go on 1.1.x branch.
Critical fixes go in 1.0.x branch.
4. Release 1.1.0 final release and stop support for 1.0.x releases.
5. Continue development on 1.2.x branch and provide maintenance
releases for 1.1.x release.

I would appreciate feedback.  Also if anyone in the list can see an
area that they can help with then that would be greatly appreciated.

On 7/10/07, Gianluca Sforna <gi...@gm...> wrote:
> Victor's note on
>
> http://www.mantisbt.org/bugs/view.php?id=6989
>
> prompted me to ask this on list (where I hope there is a wider
> developer audience)
>
> The question is: do we want to consider the 1.0 branch closed for
> normal bugfixes and only critical stuff is going to be included?
> If this is the case, I agree with Victor and I will refrain from
> proposing and/or fixing more stuff there, unless marked with a
> severity "major" and/or of the "security" category
>
> On the other side, I see the 1.1 branch is still undergoing feature
> additions, and this means  providing a estimated release date would be
> an hard call.
>
> In this situation I think we should ratify a shared policy for all
> developers, so that everyone knows what we still need to work on.
>
> For example, something like:
>
> ===== Development policy for open branches on repository =====
>
> ==== Before 1.1beta1 ====
> Modifications allowed for
>
> === 1.0.x branch ===
>   * bugs with category "security"
>   * bugs with severity "major" or higher
>   * anything else allowed after discussion in mantisbt-dev
>
> === 1.1.x branch (HEAD)===
>   * all bugs
>   * bugs with category "feature"
>
> ==== After 1.1beta1 ====
>
> === 1.0.x branch ===
>   * bugs with category "security"
>
> === 1.1.x branch (HEAD)===
>   * bugs with severity "major" or higher
>   * bugs with category "feature" only after discussion in mantisbt-dev
>
>
> Thoughts?
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> mantisbt-dev mailing list
> man...@li...
> https://lists.sourceforge.net/lists/listinfo/mantisbt-dev
>