[TODO] release considerations

[Hannu Nyman]

On 3.6.2016 19:02, Ted Hess wrote:
> On Fri, 2016-06-03 at 10:34 +0200, John Crispin wrote:
>
>> * a name
>>   - keep the year.month.minor pattern ?
>>   - do we want codenames ?
>>
> Prefer YY.MM.mm (codenames are good for development and branch names)

YY.MM might work also as the branch name. We already have packages & Luci 
branch names like "for-15.05".

But codenames are also nice, at least short and simple names. Kamikaze and 
Backfire were such short and simple names. But Designated Driver, Chaos 
Calmer, Barrier Breaker and Attitude Adjustment are too long for casual use, 
so in the forum discussions they have usually been referred just as AA, BB, 
or AA12.09, BB14.07 etc.


>> * set a ETA
>>   - do we want to fork or call for a feature freeze and stabilize in trunk ?
>>
> Branch and release is the best strategy. It keeps the trunk alive for future
> work and easy to merge forward after release. Also, you have a place for maint
> work after release which continues the linear history.

Earlier Openwrt release have had the problem of a rather long time period 
between branching and the final release. When the time period grows to 4-6 
months, trunk goes too much forward compared to the forthcoming release. 
Release starts to look stale. And developers' focus has tended to remain on 
trunk development (instead of the boring branch stabilising/finalising work). 
Creating new features is much more fun... And backporting those nice new 
features to the release branch still before the release would be great...

Branching might work if the period between branching and final release can 
been kept short, weeks instead of months.
Same goes also for a feature freeze: it should be kept short.

A combination might also work: 2-3 weeks' feature freeze before the rc 
version, and then branching for the rc build. And the final release rather 
quickly after that.