Suggestions for procedure going forward

[Robert Goldman]

On 11/18/15 Nov 18 -3:32 PM, Faré wrote:
> OK, so here is a concrete proposal for branch names:
> * "master" for the latest uncontroversial developments, which will become 3.2
> * various topic branches to hold controversial or incomplete changes
> * "release" for the latest release, which will remain 3.1 then become 3.2
> * "3.1" for work continued work on ASDF 3.1 after master becomes 3.2
> * "release-3.1" for stable releases of ASDF 3.1 after release becomes 3.2

This sounds mostly ok.  I kind of prefer "stable" to "3.1" for continued
work on the 3.1 series.

Rationale: "stable" can't be confused with one of our release tags, the
way a numerical branch name could be.

I hadn't thought about there being continued stable releases after we
move release to 3.2.  Hmmmmm......

One more open question:

If we move master to be the 3.2 series, then how do we number the
interim versions?  Previously, 3.1.x.y has been a release candidate for
3.1.x+1, which has been only mildly awkward.  But if we start version
numbering candidates for the next release this way, then testing with
:version really won't work, and there's some danger of version numbering
collisions between stable and testing.

We could have m.n.0.[1-] be release candidates for m.n, and just always
have the final release be m.n.1, which would keep the :VERSION tests
working.



> 
> —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
> Evolution competitively selects stable cooperative patterns.
> 
> 
> On Wed, Nov 18, 2015 at 2:37 AM, Kambiz Darabi <darabi at m-creations.com> wrote:
>> On 2015-11-17 18:11 CET, Robert Goldman <rpgoldman at sift.net> wrote:
>>
>>> [...]
>>> So I'd like to split ASDF development into stable and testing or
>>> something like that.
>>>
>>> Does anyone have experience doing that?  If so, please post suggestions
>>> for process to ASDF-devel.
>>
>> If we have to support version 3.x and 4.y of a code base, then we create
>> a 'release-3' branch at feature freeze time and keep it after release,
>> so 3.1, 3.2 etc. are created from the tip of 'release-3' where we
>> cherry-pick (mostly bugfix) changes from master.
>>
>> In the meantime, development of version 4 continues in master and when
>> we freeze the features for that version, we create a 'release-4' branch
>> which is then curated until 4.1 can be released.
>>
>> This is a quite transparent model which most developers understand
>> immediately.
>>
>> HTH
>>
>>
>> Kambiz
>>
>