[Phpmyadmin-devel] CVS tags and branches [was: Re: 2.7.1 roadmap]

[Marc Delisle]

Sebastian Mendel a écrit :
> Marc Delisle schrieb:
>> Sebastian Mendel a écrit :
>>> Marc Delisle schrieb:
>>>> Michal Čihař a écrit :
>>>>> Hi
>>>>>
>>>>> I meant just tag names, to conform PEAR. The structure is up to us.
>>>>> Well I'd anyway prefer using something else what support branches
>>>>> better than CVS as CVS sucks in this field, especially in merging
>>>>> changes across branches.
>>>>>
>>>>> I'd suggest to use following:
>>>>>
>>>>> HEAD
>>>>>  - QA_2_7_0 (branch)
>>>>>    - RELEASE_2_7_0 (tag)
>>>>>    - MAINT_2_7_0 (optional, branch point is RELEASE_2_7_0)
>>>>>       - RELEASE_2_7_0_1 (former 2.7.0-pl1)
>>>>>       - RELEASE_2_7_0_2 (former 2.7.0-pl2)
>>>>>    - RELEASE_2_7_1 (tag)
>>>>>    - MAINT_2_7_1 (optional, branch point is RELEASE_2_7_1)
>>>>>  - QA_2_8_0 (branch)
>>>>>    - RELEASE_2_8_0 (tag)
>>>>>    - MAINT_2_8_0 (optional, branch point is RELEASE_2_8_0)
>>>>>    - RELEASE_2_8_1 (tag)
>>>>>    - MAINT_2_8_1 (optional, branch point is RELEASE_2_8_1)
>>>>>
>>>>> And so on.
>>>>>
>>>> - QA_2_8 (branch, created from HEAD when 2.8 is feature frozen)
>>>>   - RELEASE_2_8_0RC1 (tag) phpMyAdmin-2.8.0rc1
>>>>   - RELEASE_2_8_0 (tag)    phpMyAdmin-2.8.0
>>>>   - RELEASE_2_8_0_1 (tag)  phpMyAdmin-2.8.0.1 (was pl1)
>>>>   - RELEASE_2_8_0_2 (tag)  phpMyAdmin-2.8.0.2 (was pl2)
>>>>   - RELEASE_2_8_1RC1 (tag) phpMyAdmin-2.8.1rc1   (no new features in the
>>>> 2.8 branch)
>>>>   - RELEASE_2_8_1 (tag)    phpMyAdmin-2.8.1
>>>>
>>>> - QA_2_9 (branch, created from HEAD when 2.9 is feature frozen)
>>>>   - RELEASE_2_9_0 (tag)
>>>>   - RELEASE_2_9_0_1 (tag)
>>>>   - RELEASE_2_9_1 (tag)
>>>>
>>>> I don't see the need for MAINT structure.
>>>> Branch/Tag names match with file names.
>>> - QA_2_8 (branch, created from HEAD when 2.8 is feature frozen)
>>>   - RELEASE_2_8_0RC1 (tag) phpMyAdmin-2.8.0rc1
>>>   - RELEASE_2_8_0 (tag)    phpMyAdmin-2.8.0
>>>   - RELEASE_2_8_1 (tag)  phpMyAdmin-2.8.1 (was pl1)
>>>   - RELEASE_2_8_2 (tag)  phpMyAdmin-2.8.2 (was pl2)
>>>   - RELEASE_2_8_3RC1 (tag) phpMyAdmin-2.8.3rc1   (no new features in the
>>> 2.8 branch)
>>>   - RELEASE_2_8_3 (tag)    phpMyAdmin-2.8.3
>>>
>>>
>>> release candidates for bugfix releases?
>> Yes, because a bugfix release (2.8.x) needs testing also. But you are
>> the one who suggested a fourth number for the patch level, now you no
>> longer want a fourth number?
> 
> only if required, as described below
> 
> as i wrote, i dont see big difference between normal bugfixes and
> security bugfixes

I do. Suppose we release 2.8.0 (RELEASE_2_8_0). In my suggested scheme, 
we merge fixes into the QA_2_8 branch to eventually release 2.8.1. But 
we need to release a security fix, so we open MAINT_2_8_0 based on 
RELEASE_2_8_0, put the fix and release 2.8.0.1. This is different than 
releasing 2.8.1, in the number of fixes and in the testing delay in the 
field.

So we would not have QA_2_8_0, but QA_2_8.

On the other hand, 2.8.1 would have a RC because of the bigger number of 
fixes.

> 
> 2_8_0_1 is only required if there are more changes in the 2_8 BRANCH
> after 2_8_0 RELEASE what should not go into this release (f.e. needs
> more testing)
> 
> but i don't think that this will happen much often, if a bugfix is
> really such bug that it need heavy testing it should go into next 2_X (HEAD)
> 

Agreed, a bugfix must not be too much disrupting in the logic.

> because than it is like a new feature, it is possible that this also
> changes things not wanted/expected by the user in a bugfix only release
> 
> 
>>> i don't think that its a big different between normal bug fix releases
>>> and security fix releases -  and the need for RC is equal in booth cases
>>>
>>>
>>> MAINT_X_X_X can be created as required
>>>
>>> for example, a big bugfix merged into QA_2_8 needs more testing
>>> but a security fix needs immediate release
>> That's why I suggest a 2.8.1RC1.
>>> create MAINT_2_8_0 from release tag RELEASE_2_8_0
>>> and merge the security fix and release 2.8.0.1
>>>
>>> but only if current QA_2_8 is not ready for release
>>>
>> I got your point. But this could be called also QA_2_8_0.
> 
> but this follows not the PEAR cvs standard as i read it ... or?
> 
> 
Ok, so let's name this MAINT.

Marc