On 06/21/2012 03:18 PM, Ademar de Souza Reis Jr. wrote:
> On Thu, Jun 21, 2012 at 02:12:14PM -0300, Cleber Rosa wrote:
>> On 06/21/2012 12:30 PM, Ademar de Souza Reis Jr. wrote:
>>> On Thu, Jun 21, 2012 at 10:54:12AM -0400, Chris Evich wrote:
>>>> On 06/21/2012 10:40 AM, Lucas Meneghel Rodrigues wrote:
>>>>> Hi guys,
>>>>>
>>>>> I ask your suggestions about release management.
>>>>>
>>>>> One thing that is proving to be a good decision was the creation of the
>>>>> 'next' branch. We're able to control what's going to 'master' better
>>>>> with it. But right now, we have our release tags referencing commits in
>>>>> master:
>>>>>
>>>>> 0.14.0 -> commit in master
>>>>> 0.14.1 -> commit in master
>>>>>
>>>>> So on and so forth...
>>>>>
>>>>> Now with Fedora packaging (and possibly other use cases), it is
>>>>> necessary that we extend the life cycle of a release, by having release
>>>>> based branches, say 0.14, and we would cherry pick fixes from master for
>>>>> an extended period of time, so we can release 0.14.2, 0.14.3,... so on
>>>>> and so forth.
>>>>>
>>>>> I'm inclined to go ahead and start doing it, but I'd like to hear your
>>>>> opinion about it.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Lucas
> <snip>
>
>>> Hello.
>>>
>>> My understanding is that it should be a branch for each "stable"
>>> release. I'm not sure if we have such a policy stablished
>>> already, but I would suggest this one:
>>>
>>> Version format: major.stable.minor
>>>
>>> - We're at major version 0
>>> - The "stable" (for lack of a better term) is 14
>>> - The minor (bugfix) is 1
>> ^ My original question is in much better context here: is a minor
>> release supposed to be bugfix only? AFAIK, this has not been the
>> case so far.
> My understanding is that this is exactly what Fedora guys want
> and for sure that's what I'm proposing here.
I understand your understanding is correct ;)
That's why I pointed out that this has not been the case so far, and we
need to change it.
>
>>> So, showing branches + tags:
>>>
>>> master
>>> \
>>> |...
>>> |----0.13 (branch)
>>> | \---- 0.13.0-rc1 (tag)
>>> | |---- 0.13.0 (tag)
>>> | |---- 0.13.1 ...
>>> | |---- 0.13.n
>>> |----0.14
>>> | \---- 0.14.0-rc1
>>> | |---- 0.14.0
>>> | |---- 0.14.1
>>> | |---- 0.14.2
>>> ...
>>>
>>> We never tag the master branch. Releases would be made from the
>>> stable branches. We would also commit to not break a minor
>>> release, it should include only bugfixes.
>> As of now, the master branch is tagged for releases, and a release
>> has been made out of master at a given point in time (that is, no
>> branch for stabilization or something like that). BTW, IMHO a branch
>> for stabilization is less necessary now that we have 'next'.
> We don't need a branch for stabilization, master should always be
> stable (as in "not broken"). But we should have branches for
> stable releases ("stable" as in "no behavioral changes once
> branched, only bugfixes").
Yes, that's in line with the opinion that I expressed.
>
> It shouldn't be a burden to maintain this kind of structure. But
> note: what would change is the *number of minor releases* we do.
> For example, our current 0.14.1 would be 0.15.0 in this new
> process.
>
> Minor versions should be released for the purpose of bugfixing
> only and will be interesting to third parties such as Fedora and
> stable users of autotest (that's the point of distributing
> autotest after all: we want downstream users, and these users
> want stability - as in "no behavioral changes").
Exactly. That's why I kept asking about "bug fixes only".
> That's been my point for a while (remember the previous
> discussion of splitting the tests from the repository?) We'll
> also need versioning in the autotest library and tools, as in
> "requires: libautotest > 0.14".
>
> With a larger userbase comes great responsibilities.
> (doesn't sound as good as the original, but you get my point) :)
>
> Cheers
> - Ademar
>
>>> Fedora would probably like to stick to a stable branch during the
>>> lifetime of the distro. Ditto for our external users who are
>>> concerned with stability.
>> +1
>>
>>> This kind of release management is a must if we support
>>> out-of-the tree tests.
>>>
>>> Cheers
>>> - Ademar
>>>
> <snip>
>
_______________________________________________
Autotest mailing list
Autotest@test.kernel.org
http://test.kernel.org/cgi-bin/mailman/listinfo/autotest
